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PREFACE 


This  report  was  prepared  by  the  Executive  Software  Subcommittee  established  by  the  Field  Informa¬ 
tion  Management  User’s  Group  (FIMUG)  of  the  US  Army  Corps  of  Engineers  (USAGE).  FIMUG  is  a 
field  advisory  body  to  the  Director  of  Irrformation  Management  The  Executive  Software  Subcommittee 
was  assigned  the  task  of  preparing  a  report  giving  background  on  and  discussing  issues  relevant  to  the 
mandated  transition  to  the  Ada  programming  language.  This  white  paper  is  that  report 

Much  of  the  information  presented  here  is  drawn  from  a  study  conducted  by  Dr.  Orville  E.  Wheeler, 
Memphis  State  University,  which  specifically  addressed  the  transition  of  PC-targeted  systems  develop¬ 
ment  from  a  C,  C-Scape,  dbVista  environment  to  an  environment  based  on  Ada  [29].  Ms.  Lynn  Mikulich, 
Construction  Engineering  Research  Laboratory  (CERL),  contributed  to  the  description  of  the  Rational 
Environment,  and  Mr.  Ralph  Kahn,  Oracle  Corporation,  to  the  discussion  on  Ada/Oracle  interfaces. 
Where  noted,  information  has  been  drawn  from  the  Ada  Information  Clearinghouse  (AdalC).  While 
much  work  has  gone  into  the  development  of  this  report,  it  should  be  emphasized  that  it  is  introductory, 
not  comprehensive,  in  nature;  doubtless  there  arc  questions  related  to  Ada  which  have  gone  unanswered. 
Nevertheless,  after  reading  this  document  managers  should  be  aware  of  the  broad  issues  associated  with 
the  transition  and  of  the  resources  available ,when  further  investigation  is  necessary. 

Mr.  Mark  N.  Bovelsky,  US  Army  Toxic  and  Hazardous  Materials  Agency  (THAMA),  is  Chairman 
of  the  Executive  Software  Subcommittee.  Other  members  of  the  Subcommittee  are  Mr.  Richard  Adrian, 
US  Army  Engineer  District,  Kansas  City,  Mr.  Cal  Corbin,  CERL,  Mr.  David  Furr,  Corps  of  Engineers 
Automation  Plan  (CEAP),  Mr.  Gregg  Hoge,  Cold  Regions  Research  and  Engineering  Laboratory 
(CRREL),  Dr.  Windell  Ingram,  US  Army  Engineer  Waterways  Experiment  Station  (WES),  and  .Ms.  M. 
Barbara  Schmidt,  THAMA.  Dr.  Orville  E.  Wheeler,  Memphis  State  University,  Dr.  William  A.  Ward,  Jr., 
University  of  South  /Uabama,  Ms.  Lynn  Mikulich,  CERL,  and  Mr.  Ralph  Kahn.  Oracle  CorporaUon, 
assisted  the  Subcommittee  in  compiling  this  report  Dr.  N.  Radhakrishnan,  Director,  Information  Tech¬ 
nology  Laboratory,  WES,  is  Chairman  of  FIMUG.  COL  Billy  J.  Ricks,  EN,  is  Director  of  Information 
Management  for  USAGE. 
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EXECUTIVE  SUMMARY 


This  report  addresses  issues  relevant  to  the  transition  to  the  use  of  Ada  from  a  Corps  of  Engineers 
perspective.  The  direct  discussion  of  these  issues  is  preceded  by  background  material  on  Ada  itself. 
First,  the  Department  of  Defense  (DoD)  software  crisis  that  led  to  the  development  of  Ada  is  described 
and  the  causes  undedying  it  are  presented.  Potential  solutions  to  the  crisis  are  discussed,  including  pro- 
grairuner  productivity  aids,  structured  programming,  standardization  efforts,  computer-aided  software 
engineering  (CASE)  tools,  and  research  centers.  Next,  a  brief  history  of  Ada  is  presented  to  show  how  it 
fits  into  the  Government’s  approach  to  meeting  the  crisis.  This  includes  a  description  of  the  systematic 
design  and  review  process  to  which  preliminary  versions  of  Ada  were  subjected,  followed  by  a  discus¬ 
sion  of  the  guidelines  which  apply  to  the  use  of  Ada,  including  the  Congressional  mandate  to  use  Ada 
and  the  pertinent  DoD  and  Army  regulations. 

The  second  major  section  of  this  report  discusses  the  Corps  transition  to  Ada.  This  transition  will 
involve  not  only  a  change  in  the  programming  language  used  by  the  Corps,  but  also  a  change  in  develop¬ 
ment  philosophy;  software  engineering  principles  must  be  incorporated  into  the  development  process  for 
the  transition  to  be  successful.  The  various  issues  to  be  addressed  by  the  Corps  in  order  to  accomplish 
this  are  then  presented.  The  first  of  these  is  the  selection  of  a  compiler  for  PC  platforms.  This  issue  is 
discussed  using  results  drawn  from  a  Corps-sponsored  study  which  reviewed  various  Ada  compilers  and 
development  tools.  The  importance  of  fotm^  training  for  prograntming  staff  is  stressed.  A  four-week 
sequence  of  courses  is  proposed  which  covers  object-oriented  design,  Ada  coding,  and  object-oriented 
analysis.  Other  aspects  of  training,  including  attendance  at  technical  conferences  and  acquisition  of 
relevant  literature,  are  also  discussed.  Because  of  their  importance  to  the  Corps  during  the  Ada  transi¬ 
tion,  two  special  topics  are  then  addressed:  the  Rational  Environment  (a  state-of-the-art  Ada  program¬ 
ming  support  environment)  and  use  of  Ada  with  the  Oracle  RDBMS.  CASE  tools  will  have  to  be 
acquired  to  support  this  effort;  examples  of  such  tools,  including  code  production  environments,  screen 
generators,  database  managers,  analysis  and  design  aids,  and  metrics  collectors,  are  described  to  illustrate 
the  range  of  capabilities  available. 

I 

The  report  concludes  with  recommendations  concerning  practical  steps  Corps  development  sites  can 
take  to  ensure  a  successful  transition  to  the  use  of  Ada.  The  most  immediate  of  these  are  acquisition  of 
Ada  compilers  and  programming  support  environments,  initiation  of  a  training  sequence,  selection  of 
Ada  experts  at  each  site,  and  making  a  decision  regarding  acquisition  of  the  Ration^  Environment  An 
important  long-range  recommendation  would  be  for  the  various  development  sites  to  successfully  partici¬ 
pate  in  the  Software  Engineering  Institute’s  (SEI)  Software  Process  Assessment  As  a  final  note,  readers 
should  view  the  mandate  to  use  Ada  as  an  opportunity  for  the  Corps  to  assume  a  leadership  role  within 
the  Army  in  the  area  of  software  development  The  Corps  of  Engineers  has  a  long  history  of  engineering 
many  things  well,  and  there  is  no  reason  why  the  Corps  should  not  engineer  software  well,  too. 
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Past  Problems 

Government  activities  depend  increasingly,  if  not  totally,  on  information  technology  for  their  suc¬ 
cessful  completion.  Because  declining  appropriations  are  forcing  reductions  in  manpower  while  work¬ 
loads  continue  to  increase,  this  dependence  will  accelerate  as  functional  organizations  automate  more 
and  more  tasks.  This  will  in  turn  increase  the  workload  of  information  management  GM)  they  aid 
these  organizations  in  this  automation  process.  Unfortunately,  IM  is  not  immune  from  current  budgetary 
pressures:  as  a  result,  it  must  automate  its  own  software  development  activities. 

This  fiscal  difficulty,  although  serious  enough  in  and  of  itself,  is  not  the  only  problem  faced  by 
software  developers.  There  is  another  which  has  plagued  IM  for  many  years  and  which  manifests  itself 
in  software  systems  which  are  delivered  years  late,  which  are  delivered  without  all  of  the  required  capa¬ 
bilities,  or  which  are  not  delivered  at  all.  Furthermore,  many  such  systems,  even  those  which  meet  their 
ftmctional  specifications,  perform  at  unacceptable  levels  because  they  are  designed  for  and  installed  on 
computer  systems  of  insufficient  power.  “To  illustrate  tlie  extent  of  the  problem,  consider  the  findings  of 
a  study  of  nine  DoD  software  development  contracts  totaling  $6.8  million: 

•  On  software  that  was  delivered  but  never  successfully  used,  $3.2  million  was  spent. 

•  On  software  that  was  paid  for  but  not  delivered,  $1.95  million  was  spent. 

•  On  software  that  was  delivered  and  used,  but  had  to  be  extensively  reworked  or  abandoned,  $1.3 

million  was  spent. 

•  Out  of  the  $6.8  million,  $1 19,000  was  spent  on  software  that  was  used  as  delivered. 

Unfortunately,  such  waste  is  commoa  Most  large  technical  organizations  can  chronicle  legendary 
software  disasters.’  ’  [25,  pp  2-3] 

There  are  several  reasons  for  this  system  development  crisis,  first,  many  project  managers  are 
optimistic  when  specifying  the  scope  of  a  project  because  they  want  to  solve  as  many  of  their  IM  prob¬ 
lems  as  possible.  Second,  reaching  consensus  on  automation  needs  is  time-consuming;  the  current 
method  involves  isolating  key  personnel  at  a  remote  site  for  one  or  more  months  to  analyze  needs  and 
produce  requirements.  This  is  disruptive  to  work  at  the  home  sites  and  there  is  still  no  guarantee  that 
significant  changes  in  these  requi^ments  wiU  not  be  necessary.  Third,  contractors  have  little  incentive  to 
limit  project  scope,  because  the  niore  objectives  there  are,  the  more  money  there  is  to  be  made.  Fourth, 
even  if  Government  project  managers  are  realistic  in  their  estimates  of  what  can  reasonably  be  done  in  a 
given  period  of  time,  they  generally  do  not  have  the  technical  expertise  or  the  time  to  ascertain  if  the  con¬ 
tractor  is  following  accepted  software  development  practices,  much  less  using  appropriate  modem 
software  engineering  methodologyi  Furthermore,  contractor  personnel  who  actuaUy  design  and  imple¬ 
ment  the  system  rarely  have  sufficient  software  engineering  experience  because  "graduates  of  computer 
science  programs  at  major  universities  have  never  heard  of  software  engineering,  let  alone  tools  and  tech¬ 
niques  for  producing  high-quality  so^ware  products.”  (25,  p  3] 

Potential  Solutions 

The  computing  community  has  long  recognized  the  need  to  facilitate  the  timely  production  of  large 
software  systems.  Many  of  these  have  focused  on  improving  the  productivity  of  individual  prograrr,.nets, 
including  the  invention  of  assemblers  (to  replace  the  use  of  machine  language),  compilers  for  third 
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generation  high-level  languages  (to  replace  the  use  of  assemblers),  fourth-generation  language  processors 
(to  replace  use  of  compilers),  full-screen  language-specific  editors  (to  replace  use  of  keypunches  and  line 
editors),  the  use  of  source  code  version  control  tools  such  as  make  and  sees  (to  reduce  the  complexity  of 
the  cdit-compile-test  cycle),  and  the  use  of  structured  programming  (to  reduce  the  complexity  of  the 
software  itself). 

The  Government  has  also  initiated  a  number  of  efforts  to  resolve  the  software  development  crisis. 
Perhaps  the  most  successful  of  these  are  the  standardization  activities,  including  the  establishment  and 
ongoing  revision  of  the  Federal  Information  Processing  Staitdards  (FIPS)  [12]  by  the  National  Institute  for 
Standards  and  Technology  (NIST,  fonnerly  the  National  Bureau  of  Standards);  these  FIPS  address  issues 
ranging  from  hardware  data  formats  to  programming  language  features.  More  recent  efforts  at  standardi¬ 
zation  include  the  required  use  of  Ada  for  all  new  DoD  software  projects  and  the  establishment  of  stan¬ 
dard  documentation  formats  (DoD-STD-2167/2167A).  Other  organizations  are  also  active  in  this  pro¬ 
cess,  including  the  Institute  for  Electrical  and  Electronic  Engineers  (IEEE),  which  has  promulgated  stan¬ 
dards  for  software  engineering  and  software  quality  assurance  [1,2,4],  as  well  as  the  American  National 
Standards  Institute  (ANSI),  and  the  International  Standards  Organization  (ISO),  which  have  produced 
standards  for  various  programming  languages.  Finally,  there  are  de  facto  standards  which  exist  by  virtue 
of  their  widespread  use;  examples  include  operating  systems  (DOS,  MVS,  and  UNIX)  window  environ¬ 
ments  (Microsoft  Windows  and  the  X  Window  System),  and  printer  control  languages  (HPPCL  and 
PostScript). 

Unfortunately,  use  of  programmer  productivity  aids  is  uctical  in  nanire  because  it  addresses  only 
the  implementation  phase  of  the  software  life  cycle.  The  standardization  efforts  are  an  example  of  a 
more  ^obal  approach,  but  enforcing  use  of  such  standards  by  contractors  is  sometimes  difficult  for  non¬ 
technical  personnel,  and  in  any  case  such  efforts  do  not  go  far  enough  toward  addressing  the  real  issues. 
What  is  needed  is  a  more  strategic  approach;  experts  in  both  the  academic  and  commercial  worlds  have 
recognized  this  and  a  num.ber  of  possible  approaches  have  been  proposed,  including  groupware  (GW), 
computer-aided  software  engineering  (CASE)  tools,  object-oriented  design  (ODD),  object-oriented  pro¬ 
gramming  (OOP),  and  rapid  prototyping. 

DoD  has  recogruzed  the  potential  of  such  methods  and  has  established  several  centers  to  encourage 
further  software  engineering  research  and  to  transfer  this  technology  to  DoD  projects.  These  centers 
include  the  SEI,  at  Camegie-Mellon  University  in  Pittsburgh,  the  US  Army  Software  Engineering  Direc¬ 
torate  at  Fort  Monmouth,  the  US  Army  Institute  for  Research  in  Management  Information,  Communica¬ 
tions,  and  Computer  Science  (AIRMICS)  at  the  Georgia  Institute  of  Technology,  and  the  US  Air  Force 
Software  Technology  Support  Center  (STSQ  at  Hill  Air  Force  Base.  Other  DoD  programs  that  address 
software  engineering  issues  include  the  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 
Joint  Program  Office,  partially  sponsored  by  the  Defense  Advanced  Researched  Projects  Agency 
(DARPA),  and  the  Data  and  Analysis  Center  for  Software,  which  provides  the  DoD  with  data,  informa¬ 
tion,  products,  and  services  in  order  to  facilitate  technology  transition. 

A  History  of  Ada 

Why  has  Ada  been  selected  by  DoD  as  the  required  high-order  language?  How  does  it  fit  into  the 
solution  rqjproach  described  above?  To  answer  these  questions,  some  background  on  the  history  of  Ada 
is  required.  A  study  performed  during  1973  and  1974  revealed  that  the  Department  of  Defense  was 
spending  $3  billion  per  year  on  software,  that  this  cost  was  steadily  rising,  and  that  most  of  the  cost  was 
consumed  not  by  development  of  new  systems,  but  by  maintenance  of  old  systems.  The  rea'  ns  for  this 
were  apparent;  DoD  software  projects  were  so  t.pecial«zed  that  the  contractor  who  originally  developed 
the  system  was  almost  invariably  the  only  one  who  could  maintain  it,  thus  limiting  competitiveness  and 
eliminating  any  incentive  to  cut  costs  [22,  p  2]. 
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A  second  problem  was  the  use  of  obsolete  programming  languages.  “These  languages,  developed 
in  the  eariy  1960s,  did  not  support  modem  software  engineering  methods  such  as  stractured  program¬ 
ming,  data  abstraction,  top-down  program  development,  and  re-usc  of  general  purpose  components. 
They  provided  no  way  of  checking  that  separately  compiled  pieces  of  a  program  were  consistent  A 
modem  programming  language  was  needed  to  provide  (1)  support  for  program  sjjecification  and  valida¬ 
tion,  (2)  better  error  checking  and  therefore  more  reliable  programs;  and  (3)  device-level  input  and  out¬ 
put,  real-time  operations  without  assembly  language  inserts.”  [22,  p  2) 

This  situation  was  further  aggravated  by  contractor  use  of  project-specific  programming  languages 
or  platform-specific  versions  of  “standard”  languages.  “Because  so  many  languages  were  being 
developed  for  a  single  use,  tools  that  could  reduce  the  cost  of  developing  and  maintaining  programs  in  a 
particular  language  were  very  rarely  built.  Those  tools  that  were  built  -  compiler,  linkers,  editors,  and 
configuration  control  tools,  among  others  -  were  rarely  shared  by  different  projects.”  [22,  p  2] 

The  findings  of  the  1973-1974  study  led  to  the  establishment  of  the  High  Order  Language  Working 
Group  (HOLWG),  which  was  charged  with  identifying  a  standard  language  for  use  throughout  DoD,  par- 
ticulady  for  embedded  systems.  The  HOLWG  included  members  from  the  Office  of  the  Secretary  of 
Defense,  all  three  branches  of  the  military,  the  DARPA,  the  Defense  Communications  Agency,  and  the 
National  Security  Agency.  The  initial  requirements  for  this  language,  tentatively  named  DoD-1,  were 
released  in  April  1975  and  circulated  within  the  Government  and  to  selected  outside  experts  in  the  field 
of  programming  languages.  This  requirements  document,  termed  “Strawman,”  was  subsequently 
revised  to  produce  “Woodenman”  in  August  1975  and  “Tinman”  in  January  1976;  each  revision  incor¬ 
porated  recommendations  provided  by  reviewers  from  government,  industry,  and  academia.  After  fiirther 
study,  the  HOLWG  aiuiounced  in  January  1977  that  no  existing  language  satisfied  the  Titunan  require¬ 
ments.  The  Tinman  requirements  were  rewrtten  in  the  form  of  an  actual  language  specification,  dubbed 
“Ironman,”  and  an  for  a  language  design  was  released  in  April  1977.  Following  an  incremental 
review  spanning  two  years  in  which  the  number  of  designs  was  narrowed  from  seventeen  to  four  to  two, 
the  design  proposed  by  CII-Honeywell  Bull  was  accepted.  The  formal  language  specification  was  ulti¬ 
mately  published  in  1983  as  ANSI/MIL-STD-1815A-1983,  and  as  a  FIPS  [3]. 

Since  the  standardization  of  the  Ada  language  specification  in  1983,  DoD  has  steadily  moved 
towards  adopting  Ada  as  the  standard  language  for  systems  development.  Initially,  requirements  for  the 
use  of  Ada  applied  only  to  embedded  weapons  systems.  Even  then,  it  was  sometimes  possible  to  obtain 
waivers  to  these  requirements.  However,  concerns  about  runaway  software  development  costs,  coupled 
with  the  recognition  that  use  of  Ada  throughout  DoD  would  result  in  major  cost  savings,  prompted  more 
stringent  regulations.  On  2  April  1987,  DoD  issued  Directive  3405.1  which  stated,  “The  Ada  program¬ 
ming  language  shall  be  the  single,  common,  computer  programming  language  for  Defense  computer 
resources  used  in  intelligence  systems,  for  the  command  and  control  of  military  forces,  or  as  an  integral 
part  of  a  weapons  system.  Programming  languages  other  than  Ada  that  were  authorized  and  being  used 
in  full-scale  development  may  continue  to  be  used  through  deployment  and  for  software  maintenance, 
but  not  for  major  software  upgrades.  Ada  shall  be  used  for  all  other  application.-,  except  when  the  use  of 
another  approved  higher  order  language  is  more  cost-effective  over  the  application’s  life-cycle,  in  keep¬ 
ing  with  the  long-range  goal  of  establishing  Ada  as  the  primary  DoD  higher  order  language  (HOL).”  [5] 
In  this  context,  a  major  software  upgrade  is  defined  to  be  “redesign  or  addition  of  more  than  one-third  of 
the  software.”  The  complete  text  of  this  directive  is  given  in  Appendix  A. 

HQDA  emphasized  the  Army’s  adherence  to  this  policy  in  LTR  25-90-1,  issued  on  16  July  1990, 
which  specifically  addressed  “Implementation  of  the  Ada  ftogramming  Language.”  This  letter  stated, 
"’The  Ada  programming  language  as  defined  in  ANSI/MIL-STD-1815A-1983  is  the  single,  common, 
high  order  computer  programming  language  for  all  computer  resources  used  in  the  Anny  unless  another 
language  is  mandated  by  a  higher  level  directive.  Existing  software  need  not  be  rewritten  in  Ada  solely 
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for  the  purpose  of  converting  to  Ada.  All  systems,  however,  will  transition  to  Ada  when  the  next 
haidwaie/software  upgrade  requires  modification  of  more  than  one-third  of  the  existing  code  over  the 
system  life  cycle,  unless  a  waiver  is  obtained.”  [6]  Waivers  are  not  necessary  for  use  of  (1)  off-the-shelf 
software  requiring  no  Government  maintenance  or  modification,  (2)  SQL  as  an  interface  to  a  DBMS,  (3) 
non-SQL-compliant  4GLs  to  produce  prototypes  or  systems  with  a  useful  life  of  less  than  3  years,  and  (4) 
machine  or  assembly  language  in  perfonnance  critical  situations  when  the  ratio  of  non- Ada  to  Ada 
source  code  does  not  exceed  15%  and  the  non-Ada  code  is  not  more  than  10,000  lines.  All  other  situa¬ 
tions  require  waivers.  Requests  for  waivers  must  be  accompanied  by  a  thorough  cost  and  technical 
analysis  which  cleady  demonstrates  the  cost  effectiveness  of  the  proposed  language.  The  complete  text 
of  tl:^  letter  is  given  in  Appendix  B. 

Fmally,  on  5  November  1990,  the  President  signed  the  FY  1991  DoD  appropriations  bill  (Public 
Law  101-511)  Section  8092  of  this  law,  popularly  known  as  the  “Ada  Mandate,”  states,  “Notwithstand¬ 
ing  any  other  provisions  of  law,  after  June  1,  1991,  where  cost  effective,  all  Department  of  Defense 
software  shall  be  written  in  the  programming  language  Ada,  in  the  absence  of  special  exemption  by  an 
official  designated  by  the  Secretary  of  Defense.”  [7]  Supporting  information  on  this  law  is  given  in 
Appendix  C. 

The  Superiority  of  Ada 

Responses  to  these  policy  statements  from  the  software  development  community  have  often  been 
quite  skeptical,  and  many  still  question  Ada’s  purported  cost  benefits.  From  a  scientific  perspective,  one 
of  the  strongest  challenges  has  come  from  adherents  of  object-oriented  design  (OOD)  and  object-oriented 
programming  (OOP).  This  relatively  recent  technology  emphasizes  the  correspondence  between  objects 
and  operations  in  the  real  world  and  data  types  and  operations  in  a  software  system.  It  promises  order- 
of-magnitude  improvements  in  software  development  productivity.  Although  object-oriented  principles 
and  methodologies  are  generally  language  independent,  several  languages  have  been  designed  to  provide 
object-oriented  features.  Smalltalk,  at  the  same  time  a  programming  environment  and  a  programming 
language,  is  preeminent  in  this  respec:.  It  claims  to  be  a  pure  object-oriented  language,  but  it  typically 
makes  heavier  demands  on  system  resources  than  general-purpose  procedural  languages,  and  few  large 
software  systems  have  been  implemented  in  However,  these  particular  criticisms  are  not  valid  for 
Ada’s  strongest  challenger,  C-h-.  This  language  was  designed  to  directly  support  object-oriented  tech¬ 
niques  and  at  the  same  time  be  completely  upward  compatible  with  C.  In  an  attempt  to  obtain  a  waiver  to 
the  use  of  Ada,  the  Air  Force  conduaed  a  study  to  determine  the  relative  cost  effectiveness  of  Ada  and 
C++  [10].  (An  overview  of  the  Air  Force  report  is  given  in  Appendix  D.)  Surprisingly,  the  study  deter¬ 
mined  the  opposite  of  what  many  anticipated;  Ada,  not  C+V,  was  found  to  be  superior. 

i 

This  study  consisted  of  four  substudies  which  comped  the  two  languages  from  various  perspec¬ 
tives.  The  first  substudy,  performed  by  the  Institute  for  Defense  Analyses  GDA),  addressed  tools, 
environments,  and  training.  Their  report  concluded  that  there  are  more  US  vendors  of  Ada  compilers 
than  C++  compilers  (28  vs.  18),  that  Ada  compilers  are  subjected  to  a  relatively  rigorous  validation  pro¬ 
cess  whereas  C++  compilers  cannot  be  validated  because  \no  C++  standard  even  exists,  that  Ada  has 
cross-compilation  systems  and  code  generators  while  C++  does  not,  and  that  223  universities  and  13 
DoD  installations  teach  Ada  compared  to  4  and  0,  respectivuy,  for  C++.  The  second  substudy  was  con¬ 
ducted  by  the  SEI  and  included  a  quantitative  comparison  of  the  two  languages  based  on  six  categories: 
capability,  efficiency,  availability/reliability,  maintainability^xtensibility,  life  cycle  cost,  and  risk.  Ada 
was  cleaily  superior  by  a  score  of  78.8  to  63.9  (on  a  100-point  scale).  The  third  substudy,  completed  by 
CTA,  concluded,  “Ada  projects  have  reported  15%  higher  productivity  with  increased  quality  and  double 
the  average  size.  Normalizing  these  data  to  comparable  size  pr'^ects  would  result  in  an  expected  Ada 
productivity  advantage  of  about  35%.”  Specificity,  their  data  indicated  that  C++  suffered  from  error 
rates  three  times  greater  than  Ada  (as  measured  at  the  software  formal  qualification  test).  Tne  final  study. 
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performed  by  TRW,  established  18  criteria  to  judge  the  life  cycle  cort  effectiveness  of  the  two  languages. 
A  panel  of  experts  was  then  used  to  establish  the  scores  and  weights  for  each  of  these  criteria;  the  score 
for  Ada  was  23%  higher  fOi‘  MIS  systems  and  24%  higher  for  (?  systems.  The  study’s  overall  conclu¬ 
sions  are  given  below. 

All  four  substudies  which  specifically  compared  Ada  and  C-t-f  (IDA,  SEl,  CTA,  TRW)  report 
a  significant  near  term  Ada  advantage  over  C-h-  for  all  categories  of  systems.  This  advantage 
could  be  eroded  as  C++  and  its  supporting  environments  mature  over  the  next  few  years.  On 
the  other  hand,  as  aggressive  overseas  Ada  initiatives  stimulate  even  wider  domestic  Ada 
interest,  as  Ada  tools/environments  fiitther  mature,  and  when  the  Ada  update  (Ada  9X)  is 
complete,  the  balance  could  tip  further  in  Ada’s  favor. 

Adding  to  the  case  for  Ada  is  that  the  Ada  scoring  so  well  herein  is  Ada’s  1983  version,  MBL- 
STD-1815A.  Just  as  C++  incorporates  into  C  certain  software  engineering  concepts  already 
in  Ada  (e.g.,  modularity,  strong  typing,  specificahon  of  interfaces),  so  an  Ada  update  now 
underway  wUl  bring  into  Ada  selected  features  now  included  in  C++.  'This  update,  known  as 
the  Ada  9X  Project,  is  targeted  for  completion  in  1993  [11].  The  product  of  extensive  com¬ 
munity  involvement  (including  the  C^  and  MIS  communities),  Ada  9X  will  bring  to  Ada  such 
improvements  as  decimal  arithmetic,  international  character  sets,  improved  input/output,  sup¬ 
port  for  calls  between  Ada  and  other  languages,  further  representation  specifications,  and 
inheritance/polymotphism  (popular  features  of  C++).  At  the  same  time,  Ada  9X  has  been 
designed  so  that  neither  existing  Ada  benefits  nor  performance  will  be  lost.  For  example,  Ada 
9X  inheritance  will  be  controlled  so  as  not  to  reduce  life  cycle  supportability. 

In  summary,  Ada  is  the  most  cost  effective  programming  language  for  DoD  applications. 
Specifically,  it  is  not  possible  to  make  a  credible  case  for  the  existence  of  classes  of  “more 
cost  effective”  C++  systems  compared  to  Ada.  Business  cost  effectiveness  data  collected  for 
this  study  are  typified  by  the  TRW  conclusion  that  Ada  provides  development  cost  advan¬ 
tages  on  the  order  of  35%  and  maintenmee  cost  advantages  on  the  order  of  70%.  In  terms  of 
future  life  cycle  costs,  it  will  be  some  time  before  data  exists  wliich  could  justify  a  cost  sav¬ 
ings  for  C++.  Today,  there  is  limited  life  cycle  data  available  for  Ada  and  almost  none  for 
C++. 

For  the  foreseeable  future,  then,  there  are  more  than  enough  reasons  for  the  DoD  to  stick 
firmly  with  Ada  for  all  high  order  language  (3GL  and  3-1/2  GL)  development  and  for 
exclusive  use  as  a  target  language  of  4GL  application  generators  in  the  large  class  of  applica¬ 
tions  for  which  3GL  code  must  supplement  generated  code  [10]. 

These  conclusions  carry  particular  weight  for  the  Corps  when  one  notes  that  the  study  focused  on 
information  and  Cr  systems  (not  embedded  weapons  systems),  and  that  those  who  initiated  the  study 
were  biased  toward  C++  and  against  Ada. 
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Scope  of  the  Transition 

Without  the  Ada  mandate,  the  Corps  would  have  three  alternatives  in  the  area  of  programming 
language  selection:  to  stay  with  whatever  is  currently  in  use,  to  adopt  a  more  modem  language  other 
than  Ada,  or  to  adopt  Ada.  The  first  approach  has  been  tried  for  over  a  quarter  century  and  has  proven 
ineffective.  The  most  promising  choice  for  the  second  alternative,  C-«-f,  is  still  immature,  lacking  a  stan¬ 
dard  and  associated  development  tools.  Ada,  the  third  choice,  has  proven  its  effectiveness  in  numerous 
large  projects,  has  a  standard  which  has  been  in  place  almost  ten  years  and  which  i&  rigorously  moni¬ 
tored,  and  has  a  wide  variety  of  tools  which  are  available  to  assist  programmers  and  analysts.  Even  if  the 
Government  had  not  required  the  uansition  to  Ada,  there  would  still  be  many  compelling  reasons  to  do 
so,  and  no  compelling  reasons  not  to  do  so.  Pursuing  this  third  choice  will,  however,  have  a  price.  The 
immediate  costs  will  be  associated  with  the  purchase  of  Ada  compilers  and  the  training  of  programmers. 
Learning  the  Ada  language  will  be  relatively  straightforward  for  those  developers  who  are  already 
experienced  with  Pascal  and,  to  a  lesser  extent,  C.  Those  who  have  programmed  exclusively  in  FOR¬ 
TRAN  or  Cobol  will  typically  require  a  longer  training  period. 

However,  if  the  transition  to  Ada  involved  only  a  uhange  in  programming  language,  it  would  indeed 
be  relatively  painless.  Unfortunately,  this  is  not  the  case.  Additionally,  to  maximize  the  benefits  of  the 
change,  recognized  software  engineering  principles  must  be  incorporated  throughout  the  software  life 
cycle.  More  specifically,  the  underlying  methodology  used  by  project  leaders  to  design  large  software 
systems  must  be  changed;  the  leading  contender  for  this  methodology  is  the  object-oriented  approach 
already  mentioned.  Secondly,  computer-aided  software  engineering  (CASE)  tools  must  be  acquired  to 
automate  the  development  process;  these  range  from  language-sensitive  editors  which  help  mirtimize 
syntax  errors  to  high-level  design  tools  which  facilitate  application  of  an  object-oriented  methodology. 
Finally,  application  programmers  and  analysts  must  be  equipped  with  a  development  platform  which  has 
greater  functionality  than  the  current  DOS-based  environment.  The  memory  limitations  inherent  in  DOS, 
the  absence  of  protected  mode  execution,  its  lack  of  virtual  memory,  its  inability  to  support  multiple 
users,  the  absence  of  true  multitasking  (even  with  Windows),  and  its  inability  to  support  multiple  users 
are  deficiencies  which  limit  the  productivity  of  applications  developers.  That  Microsoft  recogruzes  these 
shortcomings  is  evidenced  by  their  soon-to-be-released  NT  operating  system.  Other  candidates  include 
IBM’s  OS/2,  and  of  course,  the  more  mature  and  nonproprietary  UNIX  operating  system.  However,  these 
three  additional  issues  would  need  to  be  resolved  regar^ess  of  the  langur  je  selected;  furthermore,  they 
must  be  resolved  to  make  optimum  use  of  Ada  in  the  development  of  large  software  systems. 

Compiler  Selection 

Many  computer  manufacturers  provide  compilers  for  tlieir  own  systems  while  other  software  corn- 
parties  have  produced  cross  compilers  primarily  for  embedded  systems.  From  the  Corps’  perspective, 
however,  there  are  currently  three  major  independent  Ada  compiler  vendors:  Alsys,  Telesoft,  and  Vendix. 
Of  these  three,  Alsys  is  probably  the  vendor  of  choice  for  the  Corps’  Control  Data  (CD)  and  PC  plat¬ 
forms,  although  the  Verdix  VADS  environment  is  probably  better  for  RISC  workstations  [13].  Alsys 
offers  compilers  for  a  broad  range  of  hardware  platforms,  including  IBM-compatible  PCs  running  DOS 
and  UNIX,  various  Motorola  68(XX)-based  computers  (Apple  Macinroshes,  Apollo  Domain  workstations, 
HP  9(XX)/3(X)s,  and  Sun-3s),  most  RISC-based  workstations  and  servers  (DECstations,  IBM  RS/6000s, 
MIPS,  and  Sun  SPARC),  DEC  VAXA^MS  workstations  and  minicomputers,  and  IBM  370  series  main¬ 
frames.  'The  platforms  of  particular  interest  to  the  Corps  are  80X86  running  DOS,  to  be  discussed  below, 
and  the  Control  Data  4000  series.  Control  Data  has  licensed  the  Alsys  Ada  compiler  for  MIPS-based  sys¬ 
tems  and  has  placed  it  on  the  Corps  of  Engineers  Automation  Plan  (CEAP)  contract  The  contraa  line 
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item  number,  license  cost,  and  monthly  maintenance  charge  arc  1075TH,  $7500,  and  $125  for  the  CD 
4330, 1075TJ,  $15,000,  and  $250  for  the  CD  4360,  and  1075TK,  $20,000,  and  $334.34  for  the  CD  4680. 
This  product  consists  of  a  compilation  system,  which  includes  the  Ada  compiler,  global  optimizer,  lirker, 
library  manager,  run-time  executive,  standard  Ada  packages,  and  an  ISO-compliant  math  library,  as  well 
as  a  tool  set,  which  includes  a  source-level  symbolic  debugger,  rccompiler  to  automate  Jie  system 
rebuilds,  cross  reference  generator,  source  code  reformatter  with  user-controllable  options  to  enforce  par¬ 
ticular  coding  standards,  syntax  checker,  source  generator  to  produce  source  code  from  compilation 
units,  name  expatxler  to  convert  identifiers  visible  through  use  clauses  into  fuUy  qualified  names,  and 
profiler  tc  determine  where  execution  time  is  spent. 

Many  Corps  programmers  will  initially  use  80X86/DOS  platforms  for  their  development  work. 
Although  there  are  over  270  validated  Ada  compilers  available  today,  only  three  run  under  MS-DOS: 
RrstAda  from  Alsys,  OpenAda  from  Meridian  Software  Systems  (recently  purohased  by  Verdix),  and 
Janus/Ada  from  R&R  Software,  As  part  of  a  Corps-sponsored  study  [29],  these  three  compilers  were 
compared  using  cost,  documentation,  adherence  to  standard,  resources  required,  support  environment 
availability',  vendor  history  and  future,  upward  migration,  and  performance  as  evaluation  criteria.  The 
evaluations  were  based  on  published  reports  in  trade  Journals,  personal  ccnununication  wi‘Ji  vendor 
representatives,  documentation  supplied  with  each  product,  actual  benchmarks  performed  for  this  study, 
as  well  as  personal  experience  with  each  of  the  compilers.  Each  of  the  diree  compilers  was  assigned  a 
score  from  1  to  10  for  each  criterion  and  weights  indicating  the  relative  importance  of  each  criterion  were 
then  used  to  produce  a  weighted  average.  A  complete  description  of  the  evaluation,  including  radonale 
for  the  scores  presented  here,  is  provided  in  the  study’s  final  report  [29].  The  results  displayed  in  the  fui- 
lovifing  table  indicate  the  superiority  of  Alsys  FirstAda  (A)  over  its  Meridian  (M)  and  R&R  (R)  competi¬ 
tors.  Its  documentation  and  performance  were  clearly  better  than  the  other  two  while  recent  price  reduc- 
tons  from  Alsys  make  cost  differences  negligible  (Alsys’  volume  price  is  $973.50  each,  including  media, 
documentation,  and  one  year  of  maintenance). 


Evaluation 

Raw  Scores 

Weight 

Weighted  Scores 

Criteria 

D 

R 

Factor 

A 

M 

R 

Cost 

8 

9 

9 

5 

40 

45 

45 

Documentation 

9 

6 

2 

10 

90 

60 

20 

Standard 

9 

8 

6 

8 

72 

64 

48 

Resources 

6 

8 

9 

2 

12 

16 

18 

Environment 

8 

6 

7 

8 

64 

48 

56 

Vendor 

9 

7 

7 

7 

63 

49 

49 

Migration 

9 

6 

3 

5 

45 

30 

15 

Rsrformance 

9 

6 

2 

10 

90 

60 

20 

Aggregate 

476 

372 

271 

Percent 

86.5 

67.6 

49.3 

As  a  final  comparison,  the  well-known  Whetstone  benchmark  [23]  was  used  to  compare  the  perfor¬ 
mance  of  Alsys  FirstAda,  Microsoft  FORTRAN,  Borland  C,  and  Borland  TUrbo  Pascal.  The  tests  were 
performed  on  a  16  MHz  Zenith  386.  Using  a  full  matli  library  with  run-time  checking  disabled,  the 
results,  as  measured  in  thousands  of  Whetstone  instructions  per  second,  were  767,  650,  572,  and  111. 
Although  this  comparison  is  obviously  not  exliaustive,  it  does  indicate  that  Ada  compilers,  at  least  as 
exemplified  by  FirstAda,  are  competitive  with  other  availble  language  compilers.  Again,  further  informa¬ 
tion  on  this  benchmark  may  be  found  in  the  WES  report  [29] 
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Personnel  Training 

As  noted  earlier,  because  a  successful  transition  to  Ada  will  involve  more  than  just  changing  com¬ 
pilers.  so  will  training  programmers  to  use  Ada  involve  mote  than  teaching  Ada  syntax  and  semantics. 
Tlie  required  changes  in  tiiinking  and  working  patterns  cannot  be  induced  in  software  developers  without 
fomial  training.  This  approach  wilt  emphasize  to  the  students  the  importance  management  attaches  to 
the  Ada  trattsition.  much  more  so  than  if  they  arc  handed  a  book  and  told  to  pick  up  the  technology  on 
their  own.  This  training  should  develop  in  pcrsormel  a  new  perspective  on  the  design  of  large  software 
systems  and  encourage  the  incorporation  of  modern  software  engineering  practices  into  their  develop¬ 
ment  projects.  Based  on  successful  experience  at  CERL,  THA  viA,  and  WES,  it  is  recommended  that  this 
training  include  an  overview  of  the  software  development  crisis  and  the  history  of  Ada  (two  days), 
object-oriented  design  with  Ada  (one  week),  coding  programs  in  Ada  (two  weeks),  and  object-oriented 
requirements  analysis  (one  week).  Modem  software  engineering  principles  should  be  incorporated  into 
every  course.  No  more  than  twenty  students  should  be  in  any  class  and  only  personnel  having  prior 
experience  with  another  procedural  programming  language  should  attend.  At  least  one  or  two  weeks 
should  elapse  between  courses  to  prevent  students  from  becoming  overwhelmed  with  new  information. 
Managers  should  attend  the  design  and  analysis  courses  if  at  all  possible.  System  development  work  in 
Ada  should  follow  soon  after  the  course  work  to  pm'^dc  immediate  positive  temiorcement  of  the  con¬ 
cepts  learned  during  the  training.  When  a  large  project  is  envisioned  which  involves  development  teams 
at  different  sites  simultaneously  making  the  transition  to  Ada,  a  common  training  program  is  advised  to 
provide  a  common  technical  vocabulary,  design  methodology,  and  development  philosophy. 

The  purpose  of  the  initial  two-day  overview  session  should  be  to  motivate  the  development  staff  for 
participation  in  the  remaining  courses.  This  introduction  should  cover  the  DoD  software  development 
crisis  and  the  various  attempts  within  the  software  engineering  community  to  address  it.  The  history  of 
Ada  should  be  given  to  present  the  language  as  an  essential  part  of  the  solution  to  this  problem.  Ada 
should  be  compared  to  other  programming  languages,  noting  its  similarities,  its  unique  capabilities,  and 
the  rigorous  standardization  process  to  which  Ada  compilers  are  subjected.  Software  engineering  should 
be  inti’oduced  not  as  the  application  of  an  array  of  CASE  tools,  but  as  the  application  of  good  engineering 
management  principles  to  the  development  of  software,  i.c.,  understanding  the  problem,  planning  the 
solution,  constructing  the  design,  executing  the  design,  and  communicating  the  solution.  The  need  to 
change  from  "h-nd  crafted”  software  to  “engineered”  software  should  be  stressed,  and  the  improve¬ 
ments  in  understandability,  reliability,  maintainability,  and  efficiency  which  will  result  from  this  change 
should  be  noted.  Object-oriented  techniques  should  be  introduced  as  a  tool  to  effect  this  transition.  Case 
studies  should  be  provided  to  illustrate  the  successful  use  of  Ada  in  the  development  of  large  software 
systems.  Students  should  be  impressed  with  the  notion  that  Ada’s  overall  design  and  many  of  its  specific 
features  were  intended  to  support  software  engineering  principles  and  that  Uie  transition  to  Ada  should  be 
viewed  as  a  commitment  to  adopt  those  principles. 

The  remaining  courses  are  intended  to  provide  the  necessary  knowledge  about  the  language, 
software  engineering,  object  technology,  and  the  development  environment  to  allow  programmers  to 
begin  using  Ada.  The  object-oriented  design  (OOD)  course  should  cover  the  following  topics:  motiva¬ 
tion  for  using  object  classes  to  model  the  problem  space;  comparison  of  functional  and  object  class  prob¬ 
lem  decomposition;  introduction  to  object-oriented  design  methodology;  material  necessary  to  introduce 
the  notion  of  separate  compilation,  including  Ada  progratn  units,  program  structure,  and  the  Ada  program 
library;  the  black-box  principle  for  information  hiding  and  dau  abstraction,  including  encapsulation, 
packages,  and  private  types;  various  Ada  types,  including  integer,  floating  point,  enumeration,  record, 
array,  and  access  types;  generics  and  predefined  units.  Case  studies  should  be  provided  to  illustrate  the 
design  process  and  how  to  critique  a  design.  Exercises  should  be  assigned  to  provide  experience  in  the 
use  of  Ada  as  a  program  design  language  [14].  The  Ada  coding  course  should  cover  the  following  topics: 
overview  of  the  synux  of  various  Ada  statements;  Ada  identifiers;  subprograms,  input/output,  and 
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exceptions;  more  in-depth  coverage  of  Ada  types  than  was  provided  in  the  previous  course  including 
when  to  use  distinct  types,  subtypes,  and  predefined  types;  Ada  control  structures:  loops,  if  strtements, 
case  statements:  additional  information  on  generics;  tasking.  Class  time  should  be  about  half  lecture  and 
half  hands-on  work  on  coding  exercises  [15],  The  object-oriented  requirements  analysis  (OORA)  course 
should  cover  the  following  topics:  introduction  to  OORA:  comparison  with  other  requirements  analysis 
techniques;  role  of  object  classes,  attributes,  and  relationships  in  OORA;  use  of  state  and  process  models; 
transition  to  the  design  stage.  Practical  application  issues  should  be  addressed  through  case  studies  ar.d 
extensive  exercises  [16].  The  following  topics  from  software  engineering  should  also  be  covered  at  some 
point  in  the  course  sequence:  aims  of  software  engineering;  models  of  software  development;  require¬ 
ments  definition  and  evolution;  design  processes  and  strategies;  software  components  and  reusability; 
programming  for  reliability,  including  exception  handling  and  defensive  programming;  software  testing: 
programmer  productivity,  quality  control,  and  software  metrics. 

After  these  courses  are  completed,  steps  should  be  taken  to  maintain  staff  expertise.  Programmers 
should  be  encouraged  to  obtain  membership  in  the  ACM,  ACM  SlGAda,  and  the  IEEE  Computer 
Society.  If  possible,  the  organization  should  subscribe  to  relevant  publications  from  these  orgardzations, 
as  well  as  any  others  which  may  be  helpful.  A  recommended  list  would  include  Ada  Letters,  CrossTalk, 
Communications  of  the  ACM,  and  IEEE  Computer.  If  possible,  ACM  Computing  Surveys,  ACM  Transac¬ 
tions  on  Information  Systems.  ACM  Transactions  on  Software  Engineering  and  Methodology,  IEEE 
Software,  IEEE  Transactions  on  Software  Engineering,  and  Software:  Practice  and  Experience  should  be 
added  as  well.  This  library  should  also  include  texts  and  conference  proceedings  covering  Ada,  object- 
oriented  technology,  and  software  engineeting;  the  bibliography  at  the  end  of  this  report  should  serve  as  a 
starting  point  for  this  eflort. 

A  few  individuals  should  be  selected  to  become  the  organization's  Ada  experts.  They  should  be  the 
recipients  of  furtlier  training  on  a  regular  basis,  stay  aware  of  the  activities  of  the  Ada  Joint  Program 
Office,  and  should  also  attend  selected  conferences  and  seminars,  e.g.,  the  TRI*Ada  Symposium,  the 
Washington  Ada  Symposium,  and  the  Software  Technology  Conference.  Refer  to  Appendix  G:  Ada 
Events  Calendar  for  a  more  complete  list  of  such  events.  Furthermore,  they  should  become  familiar  with 
Ada-related  resources  available  over  the  Internet,  such  as  those  at  the  SEl,  the  Software  Technology  Sup¬ 
port  Center,  and  the  SIMTEL20  database;  these  include  technical  reports  as  well  as  repositories  of  poten¬ 
tially  reusable  Ada  software  coniponents.  The  catalog  by  Nybcrg[28]  will  be  of  particular  assistance  in 
this  respect.  In  addition  to  their  regularly  assigned  duties,  these  individuals  would  be  responsible  for 
keeping  abreast  of  advances  in  Ada  development  and  software  engineering  practice,  acting  as  consultants 
for  the  rest  of  the  development  staff,  providing  introductory  assistance  to  new  employees,  and  teaching 
short  courses  as  necessary. 

The  Rational  Environment 

Every  software  system  is  implemented  in  three  environments,  the  decision  environment,  the  design 
environment,  and  the  coding  environment.  The  decision  environment  is  that  in  which  the  system’s 
requirements  are  specified;  here  decisions  are  made  regarding  how  much  of  a  process  should  be 
automated,  what  inputs  must  be  supplied  to  the  system,  how  those  inputs  are  to  be  obtained,  what  outputs 
the  system  will  produce,  how  those  outputs  are  to  be  presented,  and  how  users  will  interact  with  the  sys¬ 
tem.  Generally,  input  into  this  decision-making  process  is  provided  by  functional  managers  and,  occa¬ 
sionally,  by  prospective  end-users  and  system  developers.  The  output  from  the  decision  environment 
provides  strategic  guidance  to  the  developers  of  the  system.  The  subsystems  ^  assigned  to  develop¬ 
ment  teams  who  may  actually  be  independent  contractors.  These  teams  are  responsible  for  taking  the 
broad  guidelines  supplied  to  them  and  incrementally  refining  the  design  until  an  actual  working  system  is 
obtained.  The  organizational  and  computational  context  in  which  this  is  done  is  tenmed  the  development 
environment;  it  is  broken  into  two  subenvirorunents,  the  design  environment  and  the  coding  environment. 
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In  the  former,  technical  managers  make  decisions  regarding  breakdown  of  subsystems  into  packages  and 
modules,  and  the  information  flow  between  them,  while  in  the  latter,  programmers  translate  the  design 
into  actual  program  text,  which  is  then  compiled,  debugged,  and  tested. 

There  are  numerous  potential  problems  in  this  process.  Because  the  magnitude  of  these  problems  is 
so  large  and  because  they  are  so  widespread,  each  is  worthy  of,  and  is  being  addressed  by,  research 
devoted  to  that  particular  field.  In  each  case  experts  are  attempting  to  apply  increased  levels  of  automa¬ 
tion  to  bring  this  software  development  crisis  under  control;  within  the  first  envirorunent,  the  current 
approach  involves  the  use  of  the  IDEF  methodology  [17]  for  business  process  modeling  and  computer- 
supported  collaborative  work  (CSCW)  techniques  such  as  electronic  meeting  systems  [27]  for  reaching 
group  consensus;  within  the  second,  CASE  tools,  such  as  code  generators,  are  proposed;  within  the  third, 
programmer  productivity  enhancements,  such  as  language  sensitive  editors,  have  been  applied. 

However,  even  if  satisfactory  solutions  are  found  to  the  problems  within  all  of  these  environments, 
the  maximum  benefit  will  not  be  obtained  unless  the  three  environments  are  integrated.  The  issue  to  be 
resolved  is  one  of  communication;  each  environment  involves  a  different  group  of  people,  each  depend¬ 
ing  on  feedback  from  the  others  to  accomplish  their  objectives.  Seamless  interfaces  between  these 
environments  must  be  developed  to  facilitate  smooth  transfer  of  knowledge  and  specifications.  THAMA 
is  currently  sponsoring  research  at  WES  to  remedy  this  situation.  This  work  involves  development  of 
prototype  interfaces  between  existing  solutions  (IDEF,  CSCW.  and  CASE)  to  make  progress  in  a  timely 
manner.  At  the  same  time  preliminary  investigations  are  under  way  to  explore  the  feasibility  of  a  single 
environment-spanning  software  system  to  provide  such  an  integrated  environment. 

The  system  which  holds  the  most  promise  for  progress  in  this  area  is  the  Rational  Environment™, 
which  currently  addresses  the  coding  environment  only.  Site  visits  to  Rational  user  sites  indicate  that  it 
is  far  superior  to  all  other  currently  available  systems  for  implementing  large  software  systems  in  Ada. 
Because  the  Rational  provides  a  programmable  interface  which  will  allow  design  tools  to  communicate 
with  it,  it  is  hoped  that  it  will  be  possible  to  extend  its  area  of  applicability  to  the  first  two  environments. 
Because  it  is  so  effective  in  enhancing  programmer  productivity,  it  is  worth  elaborating  on  its  capabili¬ 
ties. 

The  Rational  Environment  (or  simply,  "the  Rational”)  is  an  integrated,  interactive  software 
engineering  environment  for  development,  testing,  maintenance,  and  control  of  large  Ada  projects.  It 
replaces  the  usual  collection  of  edit,  make,  and  version  control  utilities  with  a  completely  integrated  sys¬ 
tem  for  program  development.  For  performance  reasons,  the  compute  intensive  portion  of  this  environ¬ 
ment  executes  on  Rational’s  own  proprietary  hardware,  the  RKXIO  processor.  This  environment  server  is 
accessed  over  an  Ethernet  through  a  software  interface  available  on  Sun  SPARC  and  IBM  RS/6(XX) 
workstations  running  the  X  Window  System,  as  well  as  PCs  running  Microsoft  Windows.  One  such 
RIOOO  processor  will  support  anywhere  from  five  to  fifteen  developers,  depending  on  the  mix  of  editing 
and  compilation.  An  influx  of  large  compilation  jobs  degrades  the  system’s  performance,  but  the  intelli¬ 
gence  built  into  the  system  reduces  the  likelihood  of  such  a  situation. 

Use  of  the  Rational  on  a  large  project  begins  with  use  of  the  Rational  Design  Facility  (RDF).  It  sup¬ 
ports  the  requirements  analysis  and  design  phases  of  the  software  life  cycle.  Ada  is  used  in  this  context 
as  a  program  design  language  (PDL)  for  requirements  capture,  software  design,  and  MIL-STD-2167A 
compliant  document  generatioa  The  RDF  also  supports  integration  with  third-party  CASE  and  desk  top 
publishing  software  packages,  including  Cadre  Teamwork™  and  Interleaf  TPS™. 

During  the  code  oevelopment  phase,  the  Rational  provides  an  intuitive  window-based  interface 
which  allows  users  to  browse  Ada  systems  according  to  syntactic  structure  or  semantic  dependencies. 
After  identifying  the  portion  of  the  code  which  is  of  interest,  programmers  use  Rational’s  Configuration 
Management  and  Version  Control  (CMVQ  feature  to  check  out  individual  procedures  or  entire  packages 
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for  development  or  modification.  This  allows  one  programmer  exclusive  access  to  some  portion  of  the 
software  and  thus  prevents  developers  from  “stepping  on  one  anotiier’s  toes.”  Rational’s  Ada-sensitive 
editor  is  then  used  to  enter  program  statements.  Ada  packages,  procedures,  functions,  loops,  and  other 
program  structures  are  automatically  closed  with  the  appropriate  end  statements,  thus  minimizing  the 
possibility  of  syntax  errors.  This  editor  also  ai’jws  cu.stomization  and  enforcement  of  site-specific  cod¬ 
ing  standards. 

Periodically,  the  current  version  of  the  program  must  be  tested.  Ada  is  a  strongly  typed  language, 
and  it  checks  subprogram  calls  with  subprogram  definitions  to  insure  argument  compatibility.  Further¬ 
more,  compilation  units  (e.g.,  subprograms  and  packages)  may  import  other  packages  in  order  to  use  their 
type  and  variable  declarations,  and  such  imported  references  must  match  the  original  declarations.  These 
relationships  between  compilation  units  are  called  dependencies  and  a  compilation  unit  which  accesses 
or  uses  the  resources  of  another  is  said  to  be  dependent  on  that  unit  Obviously,  the  dependent  unit  must 
be  compiled  after  the  unit  on  which  it  depends.  In  large  Ada  software  systems  it  is  common  for  what 
seems  to  be  a  minor  modification  to  require  recompilation  of  many  units  because  of  the  chain  of  depen¬ 
dencies.  If  such  systems  are  sufficiently  large,  the  time  required  for  recompilation  becomes  the 
bottleneck  in  the  development  process.  The  Rational  Environment  avoids  this  problem  through  iiiteUi- 
gent  dependency  checking  and  incremental  compilation.  The  former  feature  allows  the  Rational  to  avoid 
recompilation  of  dependent  units  if  a  modification  has  no  impact  (e.g.,  a  comment  was  added  or 
changed).  After  this  impact  analysis,  only  those  statements  which  are  dependent  are  recompiled.  (This 
statement  by  statement  compilation  is  possible  because  Ada  programs  ^e  stored  using  the  Descriptive 
Intermediate  Attributed  Notation  for  Ada  (DIANA)  [26].  Ada  objects  (e.g.,  statements)  are  implemented 
as  DIANA  structures  that  represent  syntactic  structure  and  include  semantic  information  and  executable 
code.  This  is  much  different  from  the  conventional  approach  of  source  code,  object  code,  and  executable 
images  that  are  stored  in  separate  files.)  | 

i 

When  a  version  of  the  software  is  required  for  the  actual  target  platform.  Rational’s  Target  Build 
Facility  allows  convenient  transfer  of  source  code  to  and  compilation  on  a  particular  host  This  process  is 
facilitated  by  the  Rational  Compilation  Integrator,  which  permits  any  third-party  Ada  compiler  to  be 
integrated  with  and  managed  by  the  Rational  Environment  This  tool  allows  developers  to  build  software 
for  multiple  platforms  (mainframe,  minicomputer,  workstation,  person^  computer)  at  the  same  time. 
With  the  Compilation  Integrator,  only  those  portions  of  the  program  (individual  unit,  unit  closure,  subsys¬ 
tem,  or,  if  required,  entire  system)  are  (te)compiled.  Obviously  this  is  niore  efficient  than  compiling  the 
entire  system  prior  to  every  test. 

I 

Periodically,  project  managers  and  team  leaders  require  information  about  the  structure  and  status  of 
the  system  under  development.  Rational  Insight™  performs  this  function  by  gathering  information  about 
Ada  units  and  subsystems  from  the  integrated  information  repository  and  then  displaying  it  in  a  graphical 
fashion.  The  resulting  diagrams  show  dependencies  among  the  various  program  structures  and  aid  in 
understanding  the  relationships  among  the  software  components.  During  system  reengineering,  this  is  an 
invaluable  capability. 

'The  SEI  performed  an  evaluation  of  the  Rational  Envirorunent  for  DoD  [24].  This  study  assessed  its 
fimaionality  in  the  areas  of  system  installation,  system  administration,  detailed  design  and  coding  func¬ 
tions,  testing  and  debugging,  compiler  quality,  configuration  management  and  project  management  func¬ 
tions.  The  results  of  this  study  were  very  positive.  THAMA,  WES,  and  CERL  have  jointly  conducted 
their  own  evaluation  of  the  Rational  Environment,  visiting  Rational’s  Washington  office  for  two  technical 
briefings  and  interviewing  Rational  users  at  four  sites  in  northern  Virginia.  Impressions  from  these  visits 
were  very  favorable.  Users  who  have  conducted  their  own  studies  have  emphasized  that  no  other 
development  environment  approaches  the  Rational  in  functionality.  These  users  have  particularly  high 
praise  for  Rational’s  customer  assistance,  stressing  Rational’s  commitment  to  the  success  of  the 
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customer’s  project  Ther ;  are.  however,  a  few  disadvantages  to  use  of  the  Rational.  It  is  quite  expensive; 
an  entry  level  system,  including  hardware  and  software,  costs  about  $250,000.  Furthermore,  a  significant 
amount  of  training  is  required  to  take  full  advantage  of  this  sophisticated  environment’s  capabilities.  In 
spite  of  this  required  investment  in  hardware,  software,  and  personnel,  the  Rational  Environment  is  capa¬ 
ble  of  increasing  productivity,  lowering  labor  costs,  and  adjusting  to  changes  in  requirements  or  target 
platforms.  For  the  forseeable  funire,  it  appears  to  be  the  best  way  to  effectively  develop  large  systems  in 
Ada. 

Ada/Oracle  Interfaces 

The  Congressional  mandate  to  use  Ada  has  posed  some  significant  technical  problems  for  those 
involved  in  MIS  system  development.  Most  MIS  systems  must  utilize  commercially  available  graphical 
user  interfaces  (GUIs)  and/or  relational  database  management  systems  (RDBMSs);  unfortunately,  the 
interfaces  between  Ada  and  these  packages  have  traditionally  b^n  rather  poor.  This  problem  is  com¬ 
pounded  by  the  lack  of  a  single  standard  in  each  of  these  areas.  For  example,  a  program  written  for  the 
MOTIF  GUI  is  not  portable  to  the  Open  Look  GUI,  much  less  to  Microsoft  Windows,  and  an  application 
which  accesses  the  Xdb  RDBMS  generally  requires  modification  in  order  to  run  with  the  Oracle 
RDBMS.  The  NIST  has  recognized  these  problems  and  responded  with  an  RDBMS  standard,  FIPSPUB 
127-1  [8],  and  a  GUI  standard,  FIPSPUB  158  [9].  Adherence  to  these  standards  by  both  software  vendors 
and  developers  will  make  development  of  portable  applications  in  Ada  much  easier. 

The  reaction  of  many  software  DBMS  vendors,  including  Oracle,  to  the  adoption  of  Ada  and  the 
development  of  standards  has  been  to  provide  bindings  between  Ada  and  their  products.  There  are 
currcnUy  four  ways  to  construct  an  Ada/RDBMS  interface:  (1)  proprietary  application  programmer  inter¬ 
face,  (2)  FIPS  127-1  compliant  embedded  SQL  precompiler,  (3)  FIPS  127-1  compliant  module  language 
compiler,  and  (4)  SQL-Ada  Module  Description  Language  (SAMeDL)  compiler.  Because  the  first 
method  is  neither  standard  nor  portable,  it  does  not  satisfy  the  Government’s  needs.  The  last  technique  is 
based  on  research  at  Carnegie  Mellon  University.  It  is  still  in  an  embryonic  stage  with  no  applicable 
standards  and  no  available  commercial  implementations.  Neither  of  these  techniques  wiU  be  discussed 
here. 


The  second  method  is  currently  the  most  widely  used  method  of  binding  Ada  programs  to  SQL- 
based  RDBMSs.  From  a  technical  perspective,  such  a  FIPS-compliant  Ada/SQL  binding  is  merely  a  way 
of  allowing  SQL  statements  to  be  embedded  in  an  Ada  program  so  that  the  program  may  exchange  infor¬ 
mation  with  a  FEPS-compliant  RDBMS.  Prior  to  actual  compilation,  such  a  program  is  first  processed  by 
a  precompiler  which  translates  the  SQL  statements  into  Ada  statements.  Oracle’s  implementation  of  this 
method,  Pro'^Ada,  was  introduced  in  1989  and  has  been  sold  to  over  300  sites  around  the  world.  It  is 
available  on  a  variety  of  platforms,  including  the  Coips’  Control  Data  CEAP  systems  as  well  as  other 
major  UNIX  platforms  (e.g.,  HP,  IBM,  SCO,  and  Sun).  Furthermore,  Pro*Ada  has  the  distinction  of 
being  the  first  Ada/SQL  embedded  SQL  binding  to  pass  the  NIST  test  for  ANSI  compliance.  It  has  since 
passed  that  test  on  many  different  platforms,  both  UNIX  and  non-UNIX.  Although  the  use  of  Pro*' Ada 
adds  an  additional  step  to  the  process  of  program  testing,  it  actuaUy  improves  programmer  productivity 
and  system  performance.  Moreover,  it  allows  dynamic  construction  of  SQL  statements  at  runtime.  The 
nature  of  these  benefits  will  be  discussed  in  the  follovring  paragraph. 

Improved  programmer  productivity  is  a  result  of  Pro* Ada’s  extensive  syntactic  and  semantic  check¬ 
ing.  All  SQL  statements  are  validated  during  precompilation  so  that  errors  may  be  detected  and 
corrected  before  the  potentially  time  consuming  compilation  and  binding  of  the  Ada  program.  During  the 
semantic  checking  phase.  Pro*' Ada  queries  the  database  to  first  determine  if  the  table  used  in  the  SQL 
statement  actually  exists,  and  then  to  see  if  the  table  has  a  column  whose  name  matches  the  one  men¬ 
tioned  in  the  statement.  These  features  save  developers  from  performing  many  useless  compilations. 
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Increased  system  performance  results  from  use  of  Pro* Ada’s  array  interface  (an  extension  to  the  FIPS 
standard).  Use  of  this  interface  allows  iasertion  or  retrieval  of  batches  of  records  with  a  single  database 
call.  For  example,  an  EXEC  SQL  FETCH  may  fetch  up  to  32K  records;  this  can  reduce  network  traffic 
because  one  fetch  of  32K  records  requires  fewer  packets  than  32K  fetches  of  single  records.  Finally, 
Pro* Ada  allows  dynamic  construction  of  SQL  statements  at  execution  time.  This  powerful  capability 
allows  construction  of  an  SQL  statement  within  a  program  variable  and  submission  of  the  statement  to 
the  RDBMS  while  the  program  is  running  (a  feature  similar  in  spirit  to  FORTRAN’S  object-time  FOR¬ 
MAT). 

The  third  method  is  the  newest  approved  standard  for  binding  Ada  programs  to  SQL-based 
RDBMSs:  it  differs  from  the  previous  approach  in  that  the  Ada  program  and  the  SQL  procedures 
(modules)  are  stored  in  separate  files.  The  SQL  file  is  translated  by  the  SQL*Module  compiler  into  Ada, 
then  compiled,  and  placed  in  an  Ada  library.  The  Ada  program  is  then  also  compiled  and  external  refer¬ 
ences  to  the  SQL  modules  are  satisfied  from  this  library.  Oracle’s  implementation  of  this  technique, 
SQL*Module,  was  announced  in  June  1992  and  should  be  available  in  the  first  half  of  1993.  Prior  to  its 
release  it  will  meet  the  NIST  test  for  FIPS-compliant  module  language  compilers. 

The  first  benefit  of  using  this  third  technique  is  the  clean  separation  of  Ada  and  SQL,  thus  improving 
maintainability  and  allowing  developers  to  specialize  in  Ada  or  SQL  without  having  to  learn  both.  It  also 
allows  developers  to  use  Ada-specific  tools  and  SQL-specific  tools  where  they  are  appropriate.  Addi¬ 
tional  productivity  is  obtained  through  the  use  of  stored  procedures.  Developers  may  store  their 
SQL*Module  procedures  in  a  database  and  access  them  from  an  Ada  program,  thus  promoting  module 
reuse. 

Finally,  another  technique  for  improving  productivity  is  the  use  of  fourth  generation  languages 
(4GLs).  Tffis  involves  specification  of  an  application  in  a  high-level  design  language  (the  4GL),  and  then 
translation  of  this  program  to  Ada.  Many  such  code  generators  are  available:  however,  the  vast  majority 
of  them  generate  package  specifications,  type  declaiations,  and  procedure  calls,  but  ffien  provide  only 
procedure  stubs.  An  exception  to  this  is  the  Oracle  product  GenerAda,  a  prototype  of  which  was  recently 
demonstrated  at  TRI-Ada  ’92.  it  creates  a  complete  application  in  Ada  which  is  compilable  and  execut¬ 
able.  Early  in  1993,  WES  wiU  be  working  with  Oracle,  under  the  sponsorship  of  THAMA,  to  test  and 
evaluate  this  product  using  a  real  application. 

Other  Tools 

Code  Production  Environments.  Even  if  the  Corps  decides  to  obtain  one  or  more  Rational  systems, 
they  will  not  be  capable  of  supporting  a  large  number  of  developers.  Cost-effective  tools  must  be  found 
to  support  the  remaining  developers.  For  this  purpose  the  Corps  requires  a  comprehensive  tool  set  con¬ 
taining  high-level  analysis  and  design  aids,  a  code  production  environment,  a  database  interface,  a  test 
generation  facility,  software  metrics  collectors,  and  project  management  tools.  These  should  be  seam¬ 
lessly  integrated  with  an  intuitive  interface  and  be  available  on  a  variety  of  platforms,  including  PCs, 
RISC  workstations,  and  CD  4000  series  servers.  Unfortunately,  such  an  environment  does  not  exist.  As 
a  first  step  in  that  direction,  the  Government  has  defined  an  Ada  Programming  Support  Environment 
(APSE)  to  assist  commercial  vendors  in  producing  comprehensive  software  engineering  environments. 
The  lowest  defined  level  is  called  a  Minimal  APSE  (MAPSE)  and  consists  of  an  editor,  compiler,  library 
management  system,  linker,  and  run  time  environment.  Except  for  the  latter  two  items,  which  are  pro¬ 
vided  by  DOS,  this  MAPSE  tool  set  is  provided  with  the  Alsys  RrstAda  compiler  via  a  menu-driven 
interface  called  Adam.  Adam  is  actually  built  on  top  of  the  Alsys  Ada  World  command  line  environment 
and  translates  menu  selections  to  AdaWodd  commands.  In  addition  to  the  MAPSE  set,  other  features 
accessible  through  Adam  include  a  verifier  (fast  synux  checker),  source  code  level  debugger,  refor¬ 
matter,  cross  referencer,  make  facility,  and  a  line  counting  metric  collector.  Users  may  substitute  their 
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own  editor  for  the  Adam  default,  and  access  to  the  operating  system  and  the  AdaWorld  command  line 
environment  is  provided.  Novice  and  expert  modes  of  operation  are  available,  which  display  few  or 
many  menu  options,  respectively.  The  Adam  interface  takes  up  a  significant  amount  of  memory.  Bind¬ 
ing  a  moderately  sized  program  will  occasionally  fail  due  to  lack  of  memory  for  symbol  tables:  this  may 
be  remedied  by  switching  to  the  command  line  environment,  Adaworld.  In  spite  of  this  minor  problem, 
experience  with  this  product  indicates  that  it  is  a  useful,  effective,  and  smoothly  integrated  system  for 
Ada  code  production  [29]. 

The  Ada  Workstation  Environment  (AWE),  marketed  by  AETECH,  is  intended  to  provide  a  full  set 
of  Ada  programming  tools.  Like  Adam,  it  is  built  on  top  of  the  Alsys  AdaWorld  command  line  environ¬ 
ment  running  under  DOS.  Its  features  include  an  editor,  library  manager,  macro  generation  facility, 
compiler-binder  control  facility,  templates  for  types  and  program  units,  and  a  menu  for  support  tools. 
These  support  tools,  which  must  be  purchased  separately,  include  an  on-line  Ada  reference  manual,  an 
on-line  computer-assisted  instruction  system,  a  hypertext  Ada  reference  manual,  an  ASQI  table,  a  border 
gra{^cs  drawing  tool,  tool  for  conversion  of  numbers  to  different  bases,  and  tools  to  perform  top-down 
structured  design,  object-oriented  design,  generation  of  source  code  from  design,  and  generation  of  pro¬ 
cedure  body  firom  procedure  specification.  The  basic  fimetions  work  very  well,  and  the  template  facility, 
not  available  in  Adam,  is  particularly  useful  in  making  skeletons  of  program  units.  Most  common  tasks 
have  a  convenient,  single  key  operation;  The  built-in  editor  has  a  native  set  of  key  functions,  but  may  be 
reconfigured  to  emulate  other  editors.  The  primary  alternative  to  AWE  is  Adam,  and  Adam’s  biggest 
advantage  is  that  it  is  bundled  with  the  Alsys  compiler.  However,  even  without  the  additional  tools, 
AWE  may  offer  enough  additional  fimctionality  to  be  considered  as  an  alternative,  but  a  decision  regard¬ 
ing  its  adoption  should  be  delayed  until  a  decision  is  made  on  whether  DOS  or  UNIX  is  to  be  the  ultimate 
development  environment. 

Screen  Generators.  Screen  Machine,  marketed  by  Objective  Interface  Systems,  is  an  interactive 
package  that  provides  a  means  of  graphically  creating  panels  on  a  screen,  editing  these  panels,  and  plac¬ 
ing  fields  in  them  using  the  PanEdit  interface.  Panel  information  is  saved  in  a  database  and  the  source 
code  to  create  these  panels  (two  complete  Ada  packages)  is  generated  by  the  program  GenCode.  To 
complete  the  interface,  the  programmer  writes  the  application  software  to  manipulate  these  screens  and 
process  the  input  data  and  then  modifies  one  of  the  package  bodies  to  handle  specific  input  selections. 
The  major  advantage  of  Screen  Machine  is  the  ease  of  producing  the  actual  panel  creation  source  code. 
The  user  has  only  to  enter  the  size,  location,  color,  number  cf  fields,  and  any  included  title  to  create  a 
panel,  and  this  is  done  through  an  interactive  screen.  Fields  can  easUy  be  added  to  this  panel  to  form  a 
database  entry  screen  or  just  an  information  panel.  The  user  is  able  to  see  the  created  panel  and  edit  it 
without  having  to  write  or  compile  any  code.  After  the  user  is  satisfied  with  the  appearance  of  a  panel, 
two  approaches  are  possible:  first,  the  Ada  program  may  access  it  as  needed  from  a  disk  file,  or  second, 
the  Ada  source  code  to  create  the  panel  may  be  generated  and  then  incorporated  into  a  progrm.  The 
former  method  minimizes  program  size,  while  the  latter  maximizes  program  execution  speed.  A  major 
disadvantage  of  the  Screen  Machine  is  its  documentatioa  The  version  evaluated  for  the  Corps  was  docu¬ 
mented  in  a  single  three  ring  binder  with  chapteis  dedicated  to  PanEdit,  GenCode,  and  the  package 
libraries.  The  text  was  readable  but  vague,  and  lacked  examples.  Furthermore,  the  index  has  not  been 
updated  to  reflect  changes  in  the  text  [29].  In  summary,  the  Screen  Machine  is  a  good  tool  for  leamiug 
the  process  of  screen  development  without  having  to  actually  program  a  screen  from  scratch.  It  enables 
the  user  to  see  the  screen  as  it  is  being  created  and  allows  one  to  make  changes  without  repetitively 
recompiling  and  relinking.  The  version  described  here  seemed  to  lack  the  functionality  required  for  more 
elaborate  I/O,  although  many  developers  at  the  Rational  user  sites  visited  by  the  Corps  were  using  it 
effectively  and  recommended  it  highly.  This  apparent  difference  in  capability  may,  however,  be  due  to 
the  Corps’s  evaluation  of  Screen  Machine  on  a  PC  running  DOS,  while  the  Rational  sites  were  using  it  on 
RlSC-b^d  workstations  tunning  UNIX  and  the  X  Window  System. 
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The  Textual  User  Interface  (TUI)  is  a  screen  development  tool  written  entirely  in  Ada  and  marketed 
by  AdaSoft,  Inc.  TUI  is  comprised  of  three  tools:  AdaWindows,  which  contains  procedures  for  window 
generation  and  control,  AdaMenus,  which  deals  with  menus  of  various  types,  and  AdaFonns,  which  deals 
with  forms  for  input  and  output.  Documentation  for  each  package  is  provided  separately  and  is  of  high 
quality.  A  facility  is  provided  for  maintaining  default  values  between  sessions  and  for  maintaining  a  his¬ 
tory  of  all  data  entered.  Some  screen  builders  are,  in  effect,  low  level  libraries  of  fimetions,  while  others, 
such  as  Screen  Machine  provide  a  much  higher  level  of  abstraction.  TUI  is  a  compromise  lying  between 
these  two  extremes.  It  is  composed  of  procedures  and  functions,  but  at  an  intermediate  level  with  much 
of  the  detail  still  hidden  from  the  user.  TUI  includes  a  number  of  useful  features;  for  example,  when  an 
editor  is  needed  in  a  held,  it  is  present  by  default  and  does  not  have  to  be  explicitly  invoked,  used,  and 
then  exited.  AdaForms  handles  I/O  for  all  standard  Ada  types  except  records  and  arrays,  strings  are  the 
only  array  type  allowed.  In  addition,  it  provides  a  List_Class,  for  selection  from  a  displayed  list,  and  a 
Text_aass,  for  I/O  of  multiple  lines  of  text.  Ada  type  checking  is  performed  on  input  data  to  a  field 
before  it  is  accepted.  The  TUI  is  a  well  designed,  logically  structured,  flexible,  well  documented  set  of 
components  for  screen  building  in  Ada,  and  is  available  for  both  DOS  and  UNIX  platforms  [29]. 

Database  Managers.  Interfaces  between  Ada  and  DBMSs  will  be  important  to  the  Corps  for  the 
development  of  management  information  systems.  Possible  interfaces  to  Oracle  have  already  been  dis¬ 
cussed;  three  additional  possibilities  are  considered  here.  The  flrst  is  AdaSAGE,  a  public  domain  data¬ 
base  generation  package  written  in  Ada  that  produces  a  complete  system,  including  interface  screens. 
The  second  alternative  would  make  use  of  two  products  marketed  by  AdaSoft:  AdaManager,  which 
creates  and  manipulates  databases,  and  AdaQuest,  which  serves  as  an  interactive  interface  to 
AdaManager.  The  third  possibility  involves  construction  of  an  Ada  “wrapper”  around  an  existing 
DBMS  (dbVista  III)  using  the  Ada  interface  pragma. 

AdaSAGE  is  a  public  domain  package  developed  and  maintained  by  the  Idaho  National  Engineering 
Laboratory  (INEL);  it  is  designed  to  facilitate  rapid  development  of  Ada  systems.  A  descendant  of  the 
SAGE  system  developed  in  FORTRAN  by  INEL  about  10  years  ago,  AdaSAGE  is  the  result  of  work  on 
the  Marine  Corps  Combat  Readiness  Evaluation  System  (MCCRES).  ENEL  produced  a  prototype  of 
MCCRES  in  Ada  for  the  Marine  Corps  in  Aisys  Ada  and  at  the  same  time  converted  SAGE  to  Ada.  Pri¬ 
marily  suited  to  MIS  applications,  its  capabilities  include  command  line  and  embedded  ANSI-compliant 
SQL,  grai^iics,  communications,  formatted  windows,  on-line  help,  sorting,  editing,  and  more.  AdaSAGE 
applications  can  be  nm  in  the  stand-alone  mode  or  in  a  multiuser  environment.  One  of  the  most  powerful 
features  of  AdaSAGE  is  the  Generic  RApid  Prototyping  l,anguage  (GRAPL).  This  interpretive  language 
allows  complete  prototyping  of  a  database  application  that  can  be  executed  interpretatively  without 
actual  compilation.  After  the  developer  is  satisfled  with  the  application,  it  is  relatively  easy  to  convert  it 
to  Ada.  Using  AdaSAGE,  it  is  possible  to  design  and  implement  an  application  in  a  minimum  of  time 
that  performs  well  and  is  easy  to  modify.  All  four  Services  have  reported  signifleant  success  in  develop¬ 
ing  applications  with  AdaSAGE;  their  experience  has  shown  AdaSAGE  to  be  equally  applicable  to  both 
sma  1  and  large  projects.  The  Government  considers  it  to  be  an  extremely  valuable  tool  and  continues  to 
fimd  its  maintenance  and  enhancement.  If  the  Corps  decides  to  use  AdaSAGE,  the  software  itself  is  free, 
but  Corps  personnel  should  attend  formal  AdaSAGE  training  provided  by  INEL,  and  one  individual  at 
each  development  site  should  join  (he  AdaSAGE  User’s  Group  ($l,6(X)/year).  As  a  member,  this  person 
will  serve  as  the  organization’s  point  of  contact  for  AdaSAGE  and  will  be  provided  with  the  following 
services:  current  versions  of  software  libraries  and  documentation,  technical  support  via  a  telephone  hot 
line,  access  to  electronic  bulletin  board  services,  newsletter  subscription,  and  invitation  to  the  annual 
meeting  held  in  Idaho  Falls. 

The  second  approach  is  the  use  of  AdaManager/Adaquest.  AdaManager  produces  a  relational  data¬ 
base  that  is  dynamically  structured  rather  than  built  on  a  static  schema.  It  allows  the  logical  structure  of 
the  data  to  be  changed,  and  additional  columns  to  be  added  without  unloading  and  reloading  the  data.  It 
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is  possible  to  insert,  delete,  update,  fetch,  select,  and  view  rows  as  well  as  join  and  save  tables,  and  re¬ 
order  rows  during  retrieval.  The  base  types  used  are  those  of  Ada  except  that  strings  are  the  only  struc¬ 
tured  types  allowed.  AdaQuest  is  an  interactive  interface  to  the  AdaManager  database  system.  It  is  a 
stand-alone  tool  containing  32  commands  (procedures)  and  provides  cither  menu  or  command  line  access 
to  all  of  the  functions  of  AdaManager.  It  is  particularly  viduable  for  constructing  databases.  AdaQuest 
can  be  used  to  define  databases,  tables,  types,  and  columns,  as  well  as  performing  administrative  tasks. 
Although  it  is  easy  to  use,  it  does  require  a  knowledge  of  AdaManager.  Documentation  is  complete,  log¬ 
ically  arranged,  and  clearly  written;  its  high  quality  is  consistent  with  that  supplied  with  other  AdaSoft 
products  [29]. 

The  final  database  interface  discussed  here  is  the  construction  of  an  interface  between  Ada  and  the 
dbVista  III  package  now  in  use  fro  PC-targeted,  THAMA-spoarored  software.  WES  has  developed  such 
an  interface,  and  it  is  currently  being  tested.  It  is  not  anticipated  that  dbVista  will  be  widely  used  with 
Ada,  particularly  for  developing  new  software,  but  the  interface  may  be  valuable  for  converting  some 
existing  programs  to  Ada  when  such  software  is  being  substanti^y  modified.  The  Ada  intenace 
modules  and  a  user  guide  are  available  from  WES. 

Analysis  and  Design  Aids.  Rational  Rose,  from  Rational,  is  a  graphical  CASE  tool  which  supports 
object-oriented  analysis  and  design.  It  is  available  on  IBM  RS/6000  and  Sun  SPARC  workstations  as  a 
stand  alone  product;  X  terminals  attached  to  those  systems  may  also  access  Rose.  It  does  not  require  the 
Rational  Environment  It  allows  developers  to  create  class  diagrams  which  serve  as  blueprints  of  high 
level  system  abstractions,  specify  class  attributes  which  provide  detailed  design  information,  and  illus¬ 
trate  the  design  through  object  diagrams  of  system  mechanisms.  Rose  uses  the  Booch  notation  [20];  it 
enforces  the  notation's  syntax  and  verifies  its  semantics  by  prohibiting  occurrences  of  multiple  inheri¬ 
tance,  as  well  as  by  checking  for  class  visibility  and  multiple  class  relationships.  All  of  the  underlying 
information  is  represented  in  ASCII,  thus  it  allows  developers  to  use  their  current  source  code  control 
system  to  manage  versions  of  the  design  just  as  they  manage  versions  of  the  code.  Rose  is  customizable 
and  extensible;  users  may  modify  menus  and  integrate  the  produa  with  other  CASE  tools.  There  are 
several  possibilities  for  output:  printed  PostScript,  encapsulated  PostScript  file,  or  FrameMaker- 
compatible  file.  A  floating  license  which  allows  a  single  copy  of  Rose  to  be  shared  among  multiple  users 
is  available  for  $3,995. 

Like  Rose,  Teamwork/Ada  is  also  based  on  the  X  Window  System.  Developed  by  Cadre  Technolo¬ 
gies,  it  is  available  on  RISC  workstations,  including  those  from  DEC,  HP,  IBM,  and  Sun,  and  also  on  X 
tenninals  cormected  to  those  hosts.  The  centerpiece  of  this  product  is  the  Ada  Structure  Graph  (ASG) 
editor,  which  allows  developers  to  create,  view,  and  change  Ada  design  components  in  a  graphical 
manner  using  the  Buhr  notauc"  [21].  Using  the  ASG.  it  is  possible  to  display  a  diagram  in  several  win¬ 
dows,  thus  allowing  detailed  editing  in  a  close-up  view  and  simultaneous  visualization  of  the  global 
impact  of  a  modification  in  a  high-level  view.  Teamwork/Ada  automates  the  transition  from  design  to 
implementation  through  integration  with  Cadre’s  Ada  Source  Builder  (ASB)  and  Design  Sensitive  Editor 
(DSE).  When  used  with  the  ASG,  these  two  tools  enforce  consistency  between  the  design  and  the  coded 
implementation,  prohibiting  changes  that  would  make  the  design  obsolete.  The  ASB  analyzes  the  output 
of  the  ASG  and  produces  Ada  code  which  corresponds  to  the  design  and  contains  "code  fi^es."  Imple¬ 
mentation  details  may  then  be  inserted  into  the  generated  code  using  the  DSE,  but  only  within  the  axle 
flames.  The  DSE  automatically  detects  Ada  syntax  errors,  and  may  be  configured  to  emulate  other  edi¬ 
tors  and  to  enforce  site-specific  coding  standaris.  Existing  Ada  o^e  may  be  processed  using  the  ASG 
Builder  which  creates  ASGs  from  source  code  in  order  to  facilitate  reuse,  reengineering,  and  mainte¬ 
nance.  Information  produced  during  this  design  process  is  saved  in  a  project  database  and  may  then  be 
accessed  by  the  Document  Production  Interface,  Teamwoik/DPl,  to  produce  documentation  compliant 
with  DoD-STD-2167A.  Teamwork/Ada  is  part  of  Cadre’s  Teamwork  environment  which  includes  facili¬ 
ties  for  simulation  of  software  systems,  construction  of  real-time  systems,  modeling  of  information,  and 
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communication  with  widely-used  DBMSs  (e.g.,  Ingres,  Oracle,  and  Sybase).  If  the  Corps  decides  to  use 
the  Rational  Environment,  Teamwork’s  interface  to  that  system  would  make  it  a  powerful  addition  to  the 
coding  environment.  If  the  Corps  decides  against  Rational,  Teamworic,  along  wi  ji  an  appropriate  compi¬ 
lation  system,  is  surely  one  of  the  top  contenders  for  an  integrated  development  environment. 

Metrics  Collectors.  An  important  aspect  of  the  development  process  is  quality  control.  Unless  data 
is  obtained  to  measure  program  quality,  this  will  be  difficult,  if  not  impossible.  One  such  tool  for  gather¬ 
ing  these  data  is  AdaMAT,  from  Dynamics  Research  Corporation.  This  is  a  static  source  code  analyzer 
which  uses  DIANA-based  metrics  to  measure  management  concerns  such  as  reliability,  portability,  and 
maintainability,  as  well  as  software  engineering  concerns  such  as  code  simplicity,  modularity,  self¬ 
descriptiveness,  clarity,  and  independence.  These  scores  are  calculated  by  calculating  the  ratio  between 
the  number  of  adherences  to  a  particular  guideline  and  the  total  number  of  adherences  and  nonadher- 
ences.  AdaMAT  is  useful  in  many  activities  throughout  a  project,  including  design  assessment,  code 
walk  throughs,  error  prevention  and  discovery,  system  installation  and  checkout,  and  maintenance. 

How  to  Proceed 

The  use  of  Ada  offers  many  advantages  over  other  languages.  Many  of  its  features  were  specifically 
intended  to  support  good  software  engineering  practice;  examples  include  its  library  consistency  require¬ 
ment  its  extremely  thorough  compile  time  checking.  Its  techriical  advantages  are  clearly  seen  and  other 
languages,  e.g.,  TVirbo  Pascal,  Modula-2,  and  C-H-,  have  attempted  to  incorporate  at  least  some  of  its 
features.  Since  Ada  is  more  advanced  than  many  other  language  systems,  it  requires  a  higher  level  of 
sophistication  for  optimum  use.  It  must  be  systematically  introduced  or  chaos  can  result 

A  well  conceived  plan  should  be  followed  which  will  promote  a  smooth  transition  to  Ada  without 
false  starts  and  wasted  effort.  The  following  paragraphs  propose  an  outline  of  this  plan.  Throughout  the 
transition,  the  key  to  success  will  lie  in  the  education  of  the  personnel  involved.  Management  must 
recognize  that  several  years  will  elapse  before  development  staff  acquire  the  expertise  and  fully  adopt  the 
techruques  that  will  produce  the  dramatic  cost  savings  advertised  by  various  Ada  proponents.  Develop¬ 
ment  staff  members  must  realize  that  formal  trairting  is  ordy  the  first  step  in  their  personal  transition  to 
Ada,  and  that  they  must  understand  and  then  put  into  practice  not  just  new  programming  language  syn¬ 
tax,  but  a  new  development  philosophy  as  well.  Furthermore,  project  sponsors  must  understand  Uiat 
software  engineering  is  engineering.  If  they  were  sponsoring  a  civil  works  project,  such  as  the  construc¬ 
tion  of  a  suspension  bridge,  they  would  not  show  up  at  the  site  a  month  after  project  initiation  and  ask 
what  percent  of  the  bridge  has  been  completed  or  ask  for  a  prototype  bridge  to  drive  over  in  order  to 
determine  its  “look  and  feel.”  They  must  understand  that  the  new  development  process  to  be  instituted 
as  part  of  this  transition  will  involve  more  irutial  plarming  and  less  time  spent  coding  and  that  the  result 
will  be  a  product  which  is  more  reliable  and  easier  to  maintain.  Finally,  everyone  should  realize  that 
some  aspects  of  the  transition  will  be  perpetual.  Specifically,  procedures  and  techniques  must  periodi¬ 
cally  evaluated  and  if  they  have  proven  ineffective,  or  if  new  technology  has  rendered  them  obsolete, 
then  they  must  be  changed. 

It  is  imperative  that  several  steps  be  immediately  taken  to  begin  the  transition  to  use  of  Ada.  If  they 
arc  not,  the  first  several  projects  implemented  in  Ada  will  be  delayed  while  developers  acquire  expertise 
in  the  Ada  language,  object-oriented  design,  and  software  engineering  methods  and  tools.  These  near- 
term  actions,  to  be  completed  during  the  first  year  of  the  transition,  include: 

1.  Acquisition  of  Ada  compilers.  Alsys  FirstAda  seems  to  be  a  good  first  choice  for  PC  platforms, 
although  if  an  interface  to  Microsoft  Windows  is  necessary,  the  Meridian  product  should  be  con¬ 
sidered,  as  well.  The  Verdix  compiler  should  be  viewed  as  a  strong  contender  for  RISC-based 
workstations. 
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2.  Acquisition  of  an  APSE  for  PC  platforms.  The  selection  of  this  environment  will  depend  on  the 
hardware/OS/compiler  combination  under  consideration.  For  80X86/DOS/Alsys,  the  Adam  inter¬ 
face  bundled  with  the  Alsys  compiler  is  a  reasonable,  cost-effective  choice.  For  RISC-based  works¬ 
tations  running  UNIX,  the  situation  is  similar  in  that  a  high-quality  APSE  is  available  from  the  com¬ 
piler  vendor,  this  is  particularly  true  of  the  Verdix  compiler  and  its  associated  VADSpro  program¬ 
ming  cnviroiunent. 

3.  Initiation  of  an  Ada  training  sequence.  Many  training  vendors,  e.g.,  EVB,  Fastrak  Training,  and 
Texel,  have  courses  that  cover  the  topics  listed  earlier.  One  should  be  selected  and  an  initial  group 
should  begin  a  formal  training  sequence. 

4.  Selection  of  potential  Ada  experts.  These  individuals  should  immediately  be  assigned  the  tasks 
noted  earlier,  specifically  those  associated  with  reviewing  current  Ada  technology  and  with  assisting 
other  developers  in  making  the  transition. 

5.  Acquisition  of  Ada  reference  materials.  These  include  the  serials  noted  previously  as  well  as  items 
from  the  bibliography. 

6.  Adoption  of  software  engineering  methodology  as  standard  practice.  This  includes,  among  other 
things,  development  of  formal  design  specifications,  application  of  object-oriented  design  tech¬ 
niques,  adoption  of  and  adherence  to  an  Ada  style  guide,  code  walkthroughs,  thorough  testing,  and 
collection  o.^softv/are  and  productivity  metrics  for  individuals  as  well  as  for  the  group  as  a  whole. 

7.  Decide  whether  or  not  to  obtain  the  Rational  Environment  This  is  an  important  initial  decision  on 
which  many  ftiture  decisions  will  depend,  including  selection  of  hardware,  compilers,  and  CASE 
tools.  Furthermore,  if  the  decision  is  positive,  then  time  must  be  allowed  to  train  personnel  in  the 
use  of  the  system. 

Other  tasks  are  equally  important  but  need  not  be  accomplished  right  away;  work  on  them  should 

begin  during  the  first  year  of  the  transition  and  be  completed  by  the  end  of  the  second.  Note,  however, 

that  some  of  them  are  ongoing  activities. 

1.  Continuous  investigation  of  available  Ada  technology.  All  of  the  areas  discussed  in  this  report 
require  constant  monitoring.  Knowledge  of  advances  in  software  engineering  methodologies.  CASE 
tools,  and  object-oriented  technology,  progress  at  Government  laboratories,  and  status  of  other 
large-scale  Ada  projects  will  all  be  useful  in  current  development  efforts. 

2.  Adoption  of  a  reuse  policy.  The  Ada  experts  noted  above  must  investigate  existing  Government 
software  repositories  to  determine  what  components  will  be  useful  to  current  projects.  A  local  reuse 
library  must  be  established. 

3.  Acquire  one  or  more  RISC-based  UNIX  workstations.  These  platfonns  support  better  CASE  tools 
and  provide  a  development  environment  with  more  functionality.  Appropriate  tools  should  be  pur¬ 
chased  simultaneously,  e.g..  Cadre’s  Teamwork,  HP’s  SoftBench,  IDE’s  ^frware  Through  Pictures, 
and  Rational  Rose.  These  should  be  tested  on  a  small  project  in  a  prototype  fashion  and  the  most 
promising  product  employed  on  subsequent  projects. 

4.  Encourage  employees  to  stay  current  in  the  field.  As  part  of  their  job  assignment,  employees  should 
periodically  review  books,  journal  articles,  case  studies,  or  products  and  prepare  a  review;  this  could 
then  be  shared  with  the  rest  of  the  staff  in  a  short  one-hour  presentation.  If  this  were  scheduled  once 
a  month,  perttaps  as  a  brown-bag  luncheon/seminar,  then  it  would  not  be  burdensome  to  the 
presenter  or  the  staff. 
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5.  Review  progress  in  making  the  transition.  This  involves  evaluation  of  all  of  the  short-term  steps 
noted  above  and  making  any  necessary  mid-course  corrections.  Specifically,  attention  should  be 
paid  to  modification  of  estimating  models  based  on  experience  with  Ada  to  date,  evaluation  and  pos¬ 
sible  revision  of  the  training  program,  review  and  enhancement  of  software  engineering  techniques 
and  tools,  and  updating  libi  ary  holdings  on  Ada  and  software  engineering, 

6.  Make  plans  for  future  efforts.  Plans  should  be  made  to  address  the  following  issues:  use  of  code 
generators,  applications  of  artificial  intelligence  in  the  project’s  functional  domain,  and  the  transi¬ 
tion  to  Ada  9X. 

7.  Plan  to  participate  in  an  SEI  Software  Process  Assessment  This  accreditation  procedure  evaluates 
an  organization’s  state  of  software  development  practice  based  on  the  SEI  Capability  Maturity 
Model.  This  scale  of  this  model’s  evaluation  ranges  from  1,  which  describes  an  ad  hoc,  chaotic 
situation  to  S,  which  describes  a  software  development  approach  that  is  repeatable,  defined, 
managed,  and  optimizing.  This  is  possibly  the  most  important  of  all  the  recommendations. 

The  mandate  to  use  Ada  should  be  viewed  as  an  opportunity  for  the  Corps  to  assume  a  leadership 
role  within  the  Army  in  the  area  of  software  development.  The  Corps  of  Engineers  has  a  long  history  of 
engineering  many  things  well,  and  there  is  no  reason  why  the  Corps  should  not  engineer  software  weU, 
too.  Hopefully  this  report  has  provided  initial  guidance  which  will  help  make  that  goal  a  reality. 
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Department  of  Defense 
DIRECTIVE 

2,  1987 
NUMBER  3405.1 

ASD(C} 

SUBJECT:  Computer  Programming  Language  Policy 

Refe.i.'c  ees:  (a)  DcD  Instruction  5000.31,  "Interim  List  of  DoD  Approved  Higher 
Order  Prograxnmlng  Languages  (HOL) , "  November  24,1976 
(hereby  canceled) 

(b)  DoD  Directive  7740.1,  "DoO  Information  Resources  Management 
Program,"  June  20,  1983 

(c)  DoD  Directive  5000.1,  "Major  System  Acquisitions,"  March  12, 
1986 

(d)  DoD  Directive  5000.29,  "Management  of  Cosputer  Resources  In 
Major  Defense  Systems,"  April  26,  1976 

(e)  through  (j),  see  enclosure  1 

A.  PURPOSE 

This  Directive  supersedes  reference  (a)  and  supports  references  (b)  and 
(e)  by  establishing  policy  for  coaputer  programming  languages  used  for  the 
de^relopment  and  support  of  all  DoD  software. 

B.  APPLXCABXLITV  AND  SCOPE 
This  Directive: 

1 .  Applies  to  the  Office  of  the  Secretary  of  Defense  (OSD) ,  the  Military 
Departsients  (Including  the  National  Guard  and  Reserve) ,  the  Organization  of 
the  Joint  Chiefs  cf  Staff  (OJCS) ,  the  Unified  and  Specified  Comnands,  the 
Inspector  General  of  the  Department  of  Defense  (XG,  DoD),  the  Defense 
Agencies,  and  nonapproprlated  fund  activities  (hereafter  referred  to 
collectively  as  "DoD  Conponents") . 

2.  Covers  all  conputer  resources  managed  under  reference  (d)  or  DoD 
Directive  7920.1  (reference  (e) ) . 

3.  Need  not  be  applied  retroactively  to  systems  that  have  entered 
full-scale  development  or  have  passed  Milestone  XX  of  references  (c)  and  (e) , 
end  for  which  a  documented  language  commitment  was  made  in  coepllance  with 
previous  policy. 

C.  DETXNXTXONS 

Special  terms  used  in  this  Directive  are  explained  in  enclosure  2; 
otherwise,  refer  to  the  "American  National  Dictionary  for  Information 
’’rocesslng  Systems"  (reference  (f ) )  . 

D.  POLXCX 
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Xt  is  DoD  policy  to: 

1.  Satisfy  functional  r«.qulra:^nta,  anhanca  laisslon  parfozmance,  and 
provlda  oparatlonal  support  through  tha  usa  of  stodam  software  concepts, 
advanced  software  technology,  software  life-cycle  support  tools,  and  standard 
programaing  languages. 

2.  Achieva  inprovaaents  in  DoD  software  nanageaent  through  the 
ispleaentation  of  processes  for  control  of  the  use  of  higher  order  languages, 
including  specification  of  standards  and  waiver  procedures. 

3.  Liiait  the  nusiber  of  prograaming  languages  used  within  the  Department 
of  Defense  to  facilitate  achieveswnt  of  the  goal  of  transition  to  the  use  of 
Ada*  (reference  (g) )  for  DoD  software  development. 

a.  The  Ada  programming  language  shall  be  the  single,  common,  coa^uter 
prograaming  language  for  Defense  coa^uter  resources  used  in  intelligence 
systems,  for  the  coamand  and  control  of  military  forces,  or  as  an  integral  part 
of  a  weapon  system.  Programming  languages  other  than  Ada  that  were  authorized 
and  being  used  in  full-scale  development  may  continue  to  be  used  through 
deployment  and  for  software  maintenance,  but  not  for  major  software  upgrades. 

b.  Ada  shall  be  used  for  all  other  applications,  except  when  the  use 
of  another  approved  higher  order  language  Is  more  cost-effective  over  the 
application's  life-cycle.  In  keeping  with  the  long-range  goal  of  establishing 
Ada  as  the  primary  DoD  higher  order  language  (HCL) . 

e.  Khan  Ada  is  not  used,  only  the  other  standard  higher  order  pro¬ 
gramming  languages  shown  in  enclosure  3  shall  be  used  to  meet  custom-developed 
procedural  language  programcJLng  requirements.  The  use  of  specific  HOL's  shall 
be  based  on  capabilities  of  the  language  to  meet  system  requirements.  Guidance 
in  selecting  the  appropriate  ROL  to  use  is  provided  in  KBS  Special  Publication 
500-117  (reference  (h) ) . 

4.  Prefer,  based  on  an  analysis  of  the  life-cycle  costs  axul  impact,  use 
of: 


a.  Off-the-shelf  application  packages  and  advanced  software  technology. 

b.  Ada -based  software  and  tools. 

c.  J^pproved  standard  BOL's. 

5.  Consider  the  potential  inpact  on  coo^tition  for  future  software 
and/or  hardware  enhancements  or  replaceatent  when  selecting  Defense,  public 
dosMiin,  or  coosiercially  available  software  packages,  or  advanced  software 
technology . 

€.  Use  life-cycle  management  practices,  as  required  by  DoD  Directive 
7920.1  (reference  (e) )  and  DoD  Directive  5000.29  (reference  (d) ) ,  for  the 
development,  support,  and  usa  of  software,  whether  custom-developed  or 
commercially  acquired. 

7.  Reduce  software  obsolescence  and  tha  cost  of  software  maintenance 
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through  use  of  approved  programnilng  languages  and  appropriate  advanced 
software  technology  during  all  phases  of  the  software  life-cycle. 

E.  RESPONSIBILITIES 

1 .  The  Assistant  Secretary  of  Defense  (Comptroller)  (ASD (C) )  and  the 
Under  Secretary  of  Defense  (Acquisition)  (USD (A))  shall  jointly: 

a.  Ensure  that  the  policy  and  procedures  in  this  Directive  are 
Ixqplenented . 

b.  Assign  responsibility  to  a  specific  DoD  Component  to  act  as  the  DoD 
language-control  agent  for  each  OoD-approved  standard  HOL. 

c.  Process  nominations  for  changes  to  the  list  of  approved  HOL's. 

2.  The  Assistant  Secretary  of  Defense  (Cos^troller)  shall: 

a.  For  automated  information  systems,  establish  programs,  as 
appropriate,  for  the  enhancement  of  the  software  engineering  process  and  the 
transition  of  such  technology  from  the  marketplace  and  research  programs  to 
application  within  general  purpose  automated  data  processing  systems. 

b.  Define  research  and  development  requirements  for  automated 
information  systems  after  consultation  with  Dol>  Coiqsonents  and  provide  s  ich 
requirements  to  USD (A)  for  inclusion  in  their  research  and  development  program. 

3.  The  Under  Secretary  of  Defense  (Acquisition)  shall: 

a.  Establish  and  support  a  software  and  information  technology 
research  and  development  program  that  is  responsive  to  the  identified  needs. 

b.  Manage  the  DoD  Ada  program  and  maintain  and  Ada  Joint  Program 
Office  (AJPO)  to  oversee  the  maintenance  of  the  Ada  language  and  the 
insertion  of  Ada-related  technology  into  the  Department  of  Defense. 

e.  Establish  research  programs,  as  appropriate,  for  the  enhancement 
of  software  engineering  technology  and  transferring  such  technology  to  use  in 
intelligen'-.a  systems  and  systems  for  the  command  and  control  of  military 
forces,  and  to  coaputer  resources  that  are  an  Integral  part  of  a  weapon  system. 

4.  The  Bead  of  Each  DoD  Conponent  shall: 

a.  Isplement  and  execute  internal  procedures  consistent  with  the 
policy  and  procedures  in  this  Directive. 

b.  Designate  a  language-control  agent  for  each  approved  HOL  for  which 
the  DoD  Coiqponent  is  assigned  responsibility  and  ensure  cosq>liance  with  the 
procedures  in  enclosure  4. 

e.  Institute  a  process  for  granting  waivers  to  the  use  of  aj^roved 
HOL's  in  accordance  with  section  r.,  below. 

d.  Specif I'ally  address  in  the  Coiqponent's  overall  cosputer  resources 
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planning  process: 

(1)  The  use  of  appropriate  advanced  software  technology  for 
developing  new  applications  and  technological  u^rades  of  existing  systems. 

(2)  The  current  use  of  assembly  languages,  nonstandard  HOL's, 
vendor  extensions,  and  enhancements  of  standard  HOL's,  and  actions  taken  to 
ensure  that  such  use  is  minimized. 

e.  Establish  a  program  for  evaluating,  prototyping,  and  inserting 
advanced  software  technology  into  the  development,  modification,  and 
maintenance  process,  and  hold  operational  software  managers  accountable  for 
investment  in  and  migration  to  advanced  software  technology  for  their 
particular  e-ivironment . 

f .  Establish  and  maintain  training,  education,  and  career  development 
programs  that  will  ensure  that  DoD  personnel  are  fully  able  to  use  new 
advanced  software  technologies. 

F.  MATVER  PROCEDURES 

1.  Waivers  to  the  policy  in  subsection  D.3.,  above,  shall  be  strictly 
controlled  and  closely  reviewed.  Authority  for  issuing  waivers  is  delegated 
to  each  DoD  Cosponent. 

a.  Each  proposed  waiver  shall  contain  full  justification  and  shall, 
at  a  minimum,  include  a  life-cycle  cost  analysis  and  a  risk  analysis  that 
addresses  technical  performance  and  schedule  ispact.  Bach  waiver  granted  by 
the  DoD  CoBponent  shall  apply  to  only  one  system  ot  subsystem. 

b.  Justification  for  granted  waivers  shall  be  provided  to  USD (A)  or 
ASD(C)  within  the  scope  of  their  individual  responsibilities,  as  periodically 
requested  for  review. 

2.  A  waiver  NEED  NOT  be  obtained  for  use  of: 

a.  Commercially  available  off-the-shelf  applications  software  that  is 
not  modified  or  maintained  by  the  Department  of  Defense. 

b.  Commercially  available  off-the-shelf  advanced  software  technology 
that  is  not  modified  or  maintained  by  the  Department  of  Defense. 

e.  Cosputer  programming  languages  required  to  inclement 
vendor-provided  updates  to  consasrcially  supplied  off-the-shelf  software.  Use 
of  such  languages  shall  be  restricted  to  isqplementing  the  vendor  updates. 

3.  A  waiver  IS  REQUIRED  for  use  of  unmodified  Defense  or  public  domain 
software  that  does  not  conform  to  the  language  requirements  of  subsection 
0.3. ,  above.  Maintenance  of  the  software  shall  be  specifically  addressed  in 
the  waiver  request  to  include  life-cycle  maintenance  costs  and  the 
availability  of  source  codes  and  necessary  software  tools. 

6.  EFFECTIVE  DATE  AND  IMPLEMENTATION 
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This  Directive  is  effective  immediately.  Forward  one  copy  of  ia^slementing 
documents  to  the  Assistant  Secretary  of  Defense  (Comptroller)  and  one  copy  to 
the  Under  Secretary  of  Defense  (Acquisition)  within  120  days. 

William  H.  Taft,  IV 
Deputy  Secretary  of  Defense 


Enclosures  -  4 

1 .  References 

2.  Special  Terms  and  Definitions 

3.  DoD-Approved  Higher  Order  Programming  Languages 

4.  Procedures  for  Controllong  Higher  Order  Languages  (HOL) 


*Ada  is  a  Registered  Trademarlc  of  the  U.S.  (^vemment  (Ada  Joint  Program 
Office) . 
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REFERENCES,  continued 

(e)  DoD  Directive  7920.1,  "Life  Cycle  Manageiaent  of  Automated  Information 
Systems  (AXS) , "  October  17,  1978 

(f)  National  Bureau  of  Standards  (NBS)  FIPS  Publication  11-2,  "American 
National  Dictionary  for  Information  Processing  Systems, "  May  9,  1983 

(g)  ANSI/MIL-STD-1815A-1983,  "Ada  Programming  Language,"  February  1983 

(b)  National  Bureau  of  Standards  Special  Publication  500-117,  "Selection  and 
Dse  of  General  Purpose  Programming  Languages, "  October  1984 

(i)  DoD  4120. 3-M,  "Defense  Standardization  and  Specification  Program  Policies 
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(j)  DoD  Directive  5010.19,  "Configuration  Management,"  May  1,  1979 
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SPECIAL  TERMS  AND  DEFINITIONS 

1.  Advanced  Software  Technology.  Software  tools,  life-cycle  support  environ 
ments  (including  program  support  environments),  nonprocedural  languages, 
modem  data  base  management  systems,  and  other  technologies  that  provide 
isprovements  in  productivity,  usability,  maintainability,  portability,  etc . , 
over  those  capabilities  commonly  in  use. 

2 .  Automated  Information  Systems .  A  collection  of  functional  user  and 
automatic  data  processing  personnel,  procedures,  and  equipment  (including 
automatic  data  processing  equipment (ADPE) )  that  is  designed,  built,  operated, 
and  maintained  to  collect,  record,  process,  store,  retrieve,  and  display 
information . 

3.  Major  Software  Upgrade.  Redesign  or  addition  of  more  than  one-third  of 
the  software . 
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DoD-J^xoved  Higher  Order  Prograssnlng  Languages 


I 

1 

Industry 

1 

I  Language 

1  Standard  Number 

DoD  Control  Agent | 

Control 

1 

I 

1 

Agent 

1 

I  Ada 

1  ANSI/MIL-STD-1815A-1983 

Ada  Joint  Program! 

ANSI 

1 

I 

1  (FIPS  119) 

Office  1 

1 

I  C/ATLAS 

1  IEEE  STD  718-1985 

Navy  1 

IEEE 

1 

I  COBOL 

1  ANSI  X3. 23-1985  (FIPS  21-2) 

Air  Force  I 

ANSI 

1 

I  CMS-2M 

1  NAVSEA  0987LP-598-2210-1982 

Navy  1 

N/A 

1 

I  CMS-2Y 

1  NAVSEA  Manual  M-5049,  M-5045t 

Navy  1 

N/A 

1 

I 

1  M-5044-1981 

1 

1 

I  rORTRAN 

1  ANSI  X3. 9-1978  (FIPS  89-1) 

1 

Air  Force  I 

ANSI 

1 

I  JOVIAL  (J73) I  MZL-STD-1589C  (USAF) 

1 

Air  Force  I 

N/A 

1 

I  Minimal 

1  ANSI  X3. 80-1978  (FIPS  88-1) 

I 

Air  Force  | 

ANSI 

1 

I  BASIC 

1 

1 

1 

I  PASCAL 

1  ANSI/IEEE  770X3.97-1983 

1 

Air  Force  j 

ANSI 

1 

I 

1  (FIPS  109) 

1 

1 

I  SPL/1 

1  SPL/1  Language  Reference 

1 

Navy  1 

N.^A 

1 

1 

1  Manual,  Intermetrics  Report 

1 

1 

1 

1  No.  172-1 

1 

1 

Note.  See  NBS  Special  Publication  500-117  (reference  (h) ) . 
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PROCEDURES  FOR  CONTROLLING  HIGHER  ORDER  LANGUAGES  (HOL) 

1.  All  Ada  conquers  that  are  used  for  creation  of  software  to  be 
delivered  to  or  maintained  by  the  Government  shall  be  formally  validated  In 
accordance  with  procedures  and  guidelines  set  by  the 

2.  Bach  DoD-approved  HOL  shall  be  assigned  to  a  DoD  language-control 
agent,  as  shown  In  enclosure  3,  who  shall: 

a.  Have  the  authority  and  responsibility  for  proper  support  of  all 
language-control  activities  needed  to  provide  for  necessary  .modification  and 
Isprovement  of  the  assigned  HOL.  The  agent  shall  operate  In  accordance  with 
DoD  4120. 3-M  (reference  (1)}. 

b.  Provide  configuration  control  for  DoD  HOL's  In  accordance  with 
DoD  Directive  5010.19  (reference  (j)}.  For  HOL's  controlled  under  Industry 
(e.g. , Institute  for  Electrical  and  Electronic  Engineers  or  American  National 
Standards  Institute)  procedures,  the  agent  shall  represent  the  Department  of 
Defense  to  the  controlling  body. 

e.  Maintain  a  single  standard  definition  of  the  assigned  HOL  and  make 
this  definition  doc;iment  available  as  a  Federal,  DoD,  military,  or  adopted 
Industry  standard.  The  agent  shall  also  gather  and  disseminate  appropriate 
Information  regarding  use  of  the  HOL,  Its  cospllers.  Interpreters,  and 
associated  tools. 

3.  A  DoD  Cooponent  may  nominate  a  language  for  removal  from  the  list 
of  approved  languages  by  submitting  a  justification  document,  which  presents 
the  rationale  for  the  proposed  deletion  and  an  Intact  analysis,  to  the 

ASD (C) ,  who  will  coordinate  It  with  USD (A) . 

4.  A  DoD  Conponent  may  also  nominate  a  language  for  Inclusion  on  the 
list  of  approved  languages  by  submitting  a  justification  document  to  the 

ASD (C) ,  who  will  coordinate  It  with  USD (A) .  The  justification  document 
shall  include  the  following: 

a.  A  detailed  rationale  for  using  the  language.  Including  bow  the 
candidate  language  sheets  specific  DoD  requirements  that  are  not  satisfied  by 
the  approved  languages. 

b.  A  description  of  the  language  and  the  environment  and  a  detailed 
unambiguous  specification  of  the  language. 

c.  An  economic  analysis  of  the  irqpact  of  the  language  over  Its 
espected  life-cycle. 

d.  A  detailed  plan  for  Irplementlng  and  supporting  the  language. 
Including  Identification  of  the  DoD  Cosponent  that  will  accept  designation  as 
control  agent  for  the  language. 
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DEPARTMENT  OF  THE  ARMT 
NASHINGTON,  D.C.  20310 


*HQDA  LTR  25-90-1 

*Thla  letter  supersedes  HQDA  Letter  25-88-5,  21  June  1988. 
SAIS-ADO  (14  May  1990}  1€  July  1990 

Bi^lres  16  July  1992 

SUBJECT:  Xsplementatlon  of  the  Ada  Programming  Language 
SEE  DISTRIBUTION 

1.  Purpose.  This  letter  aapllfies  Ara^  policy  and  guidelines 
for  inplementlng  the  Ad  programming  language  as  required  by  DOD 
Directives  3402.1  and  3405.2 

2.  References.  Related  publications  are  listed  below. 

a.  DOD  Directive  3405.1,  2  J^ril  1987,  Cosputer  Programming 
Language  Policy. 

b.  DOD  Directive  3405.2,  30  March  1987,  Use  of  Ada  in  Weapon 
Systems . 

c.  AMS1/MIL-STD-1815A-1983,  Ada  Programming  Language, 

22  January  1983. 

d.  HQDA  message,  031309Z  August  1987,  SQI>  Relational  Data 
Base  Language  Standard. 

3.  Explanation  of  abbreviations.  Abbreviations  used  in  this 
letter  are  explained  in  the  glossary. 

4.  J^plicabillty  and  scope.  This  letter  applies  to  all  computer 
resources  used  to  develop,  skodify,  maintain,  or  support  Ars^ 
software.  These  resources  include  but  an  not  limited  to 
automated  information  systems,  intelligence  systems,  tactical 
sya :ams,  and  weapon  systems  that  have  information  resources  such 
as  cooputers  as  part  of,  or  embedded  in,  |kbe  host  system.  They 
also  include  but  are  not  limited  to  systnu  developed  by  or  for 
major  commands,  program  executive  officer^ /program  managers, 
central  design  activities,  combat  developunt  faci.  itles,  and 
laboratories.  Except  in  instances  noted  iia  paragraph  6a,  this 
policy  needs  not  be  applied  retroactively  ^o  systems  that  have 
entered  full-scale  development  or  deployment  phases  of  the  life 
cycle,  or  for  which  a  waiver  has  been  approved  by  Headquarters, 
Departxaent  of  the  Arn^  (HQDA)  . 

5 .  Responsibilities 

a.  The  Director  of  Information  Systems  for  Cemmand,  Control, 
Communications,  and  Conputers  (DISC4)  will— 
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(1)  Act  as  the  Hxay  Ada  Executive  Official  and  serve  as 
the  army  focal  point  for  all  Ada  program  activities .  The  DZSC4 
will  review  and  approve  all  requests  for  exceptions  or  waivers 

(2)  Develop  and  execute  the  policy  and  plans  necessary  to 
ensure  successful  Army-wide  transition  to,  and  isplementation  of, 
the  Ada  language  and  its  associated  technology,  including 
processes  for  software  engineering  and  software  engineering 
project  management. 

b.  Major  JixwY  command  (MACOM)  commanders  and/or  program 
executive  officers  (PEOs)  will — 

<1)  Develop  appropriate  policy  to  support  an  Ada 
ixplementatlon  plan. 

<2)  Develop,  svtbmit,  maintain,  and  execute  an  Ada 
implementation  plan  in  the  format  shown  in  Jppendix  A.  The 
implementation  plan  will  be  in  two  parts  (systems  and 
organisational)  and  will  be  submitted/updated  on  an  annual  basis. 
The  systems  portion  will  address  all  major  systems  (such  as 
mission  critical  computer  resources  (MCCR) ,  Standard  Am^ 
Management  Information  System  (STAMZS) ,  command  standard,  command 
iinique,  and  'nulti-user/location)  and  those  systems  that  provide 
input  to  or  receive  output  from  these  systems.  This  portion  will 
also  include  a  schedule  for  transition  to  Ada,  as  appropriate. 

The  organizational  poxrtion  will  address  planning,  training,  and 
support  available  for  migrating  to  Ada  technology . 

(3)  Maintain,  as  a  PEO,  an  Ada  implementation  plan  for 
those  systems  under  their  purview  and  ensure  that  assigned 
program/pro ject/product  managers  (PMs)  implement  Ada  in 
accoaniance  with  Am^  policy. 

(4)  Ensure  that  software  designers /developers  are  fully 
trained  in  the  use  of  the  Ada  language,  technology,  and  software 
engineering  processes,  with  particular  emphasis  on  developing 
components  that  are  tested,  validated,  and  documented  for 
inclusion  in  reuse  libraries. 

(5)  Ensure  that  military  and  government  civilian  personnel 
in  all  software  skill  groups  are  aware  of  new  advanced  software 
technologies  for  possible  implomentatlon . 

(6)  Develop  procedures  and  guidelines  that  address  good 
software  engineering  principles  that,  as  a  odnimum,  address 
software  reuse,  portability,  and  management  controls. 

c.  Heads  of  HQDA  activities  will  develop,  maintain,  and 
submit  implementation  plans  to  the  Department  of  the  Army 
Information  Manager  (DAIM)  for  execution.  The  HQDA  staff 
agencies  and  their  field  operating  agencies  (FOAs)  are  considered 
collectively  as  a  MACOM  for  execution  of  this  letter. 
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£ .  Policy . 

a.  The  Ada  programming  language  aa  defined  In  ANSI/MXL-STD- 
1815A-1983  Is  the  single,  common,  high  order  coiif>uter  programming 
language  for  all  con^uter  resources  used  in  the  Am^  unless 
another  language  Is  mandated  by  a  higher  level  directive. 
Approvals  to  use  another  approved  standard  high  order  language 
(HOL),  as  defined  In  DOD  Directive  3405.1,  will  only  be  granted 
when  the  use  of  the  other  language  Is  estimated/calculated  to  be 
8»re  cost  effective  or  more  operationally  effective  over  the 
applications'  life  cycle.  Programming  languages  other  than  Ada 
that  were  authorized  and  are  being  used  In  full-scale  development 
of  these  systems  may  continue  to  be  used  through  deployment  and 
for  software  maintenance.  In  those  specific  Instances  where  Axmy 
systems  must  Interface  with  non-Department  of  Defense  (DOD) 
agencies,  such  as  the  Central  Intelligence  Agency  (CIA)  and 
Federal  Bureau  of  Investigation  (FBI) ,  Ada  Is  preferred  but  not 
required.  Existing  software  need  not  be  rewritten  In  Ada  solely 
for  the  purpose  of  converting  to  Ada.  All  systems,  however,  will 
transition  to  Ada  when  the  next  hardware/software  upgrade 
requires  modlflcat.iun  of  more  than  one-third  of  the  existing 
code  over  the  system  life  cycle,  \inless  a  waiver  Is  obtained. 

b.  All  requests  for  exceptions  to  use  another  approved  HOL 
will  have  fully  docvmented  rationale.  The  requests  will  address 
technical  feasibility  and  life-cycle  cost  analysis  or  cite  the 
applicable  higher  level  directive. 

c.  Nhen  software  cosq>onents  for  Ars^  systems  are  being 
acquired  and/or  developed,  good  software  engineering  principles 
will  be  exercised  to  facilitate  the  use  of  ada.  The  approach  to 
acquiring  and/or  developing  software  coaponents  will  be  based  on 
an  analysis  of  life-cycle  costs  and  operational  efficiency. 

Major  considerations  should  he: 

(1)  The  use  or  modification  of  existing  Ada  software. 


(2)  The  use  of  off-the-shelf  software  and  advanced 
software  technology,  isplemented  In  other  than  Ada,  for  which  no 
modification  or  Government  maintenance  is  required.  Advanced 
software  technology  Includes  software  tools,  life-cycle  support 
environments,  nonprocedural  languages,  azxd  modem  database 
management  systems  (DBMSs)  that  provide  Isprovements  In 
productivity,  usability,  smlntalnablllty,  and  portability.  A 
waiver  Is  not  required  for  non-developmental  Item  (NDI)  software 
application  pac)cages  and  advanced  software  technology  that  are 
not  modified  by  or  for  DOD.  In  those  Instances  where  existing 
software  requires  modification  to  ensure  the  total  system  meets 
requirements,  a  waiver  la  required  If  more  than  one-third  of  the 
source  code  la  being  changed  and  the  changes  are  not  written  In 
Ada. 

(a)  Regarding  the  use  of  fourth  generation  languages 
(4GLs),  the  following  apply: 
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1  The  approved  ad  hoc  query  and  Database 
Management  System  interface  language  for  Krmy  systems  is  the 
Structured  Query  Language  (SQL) ,  Federal  Information  Processing 
Standard  (FIPS)  127.  In  accordance  with  HQDA  message,  031309Z 
August  1987,  SQL  will  be  used  for  relational  databases  as  the 
Interface  between  programs  and  the  supporting  DBMS.  A  waiver  Is 
not  required  for  any  system  using  an  SQL-coapllant  DBMS  In 
conjunction  with  Ada. 

2  Non-SQL-coiq>llant  4GLs  may  be  used  without  the 
requirement  for  a  waiver  to  develop  prototypes  during 
requirements  definition  and  In  short  tezm/ad  hoc  applications 
(less  than  3  years'  useful  lifr).  In  no  case  will  a  non-Ada 
prototype  be  fielded  during  system  izplementatlon  nor  will  an  ad 
hoe  application  exceed  the  tims  limitation  without  an  approved 
Ada  waiver. 

(b)  With  the  exception  noted  In  subparagraph  2,  above, 
4GLs  will  not  replace  the  requirement  for,  or  the  use  of  ,  Ada. 

(3)  The  development  of  new  Ada  software.  If  source  code 
generators  are  used  In  the  development  of  Ada  software,  they  must 
produce  an  Ada  source  code  that  cosplles  with  AMSX/MIL-STD-1815A- 
1983. 

(4)  The  Ixpact  on  certain  critical  processes  that 
currently  cannot  be  performed  efficiently  in  an  HOL  due  to  timing 
and/or  siring  constraints.  These  functions,  requiring  very  fast 
or  tightly  controlled  cosputer  processing,  are  more  appropriately 
written  at  the  machine  level  (for  exanple,  micro-code/assembly 
language) .  In  such  Instances,  a  waiver  Is  not  required  If  the 
ration  of  non-Ada  source  code  to  Ada  source  coda  (terminal 
semicolon  count)  does  not  exceed  15  percent.  An  Ada  waiver  Is 
required  if  the  total  machine  level  code  exceeds  10,000  lines. 

(5)  The  requirement  that  projects  use  a  validated  Ada 
coapiler,  as  defined  by  the  Ada  Joint  Program  Office  (AJPO)  Ada 
Conpller  Validation  Procedures,  at  the  start  of  formal  testing. 
Providing  no  changes  are  made  to  the  cospller,  it  may  be  used  for 
the  balance  of  the  project ;s  life  cycle  even  though  Its 
associated  validation  certificate  may  have  expired.  If  the 
conpller  is  altered,  then  a  validation  Is  necessary. 

d.  If  system  requirements  cannot  be  satisfied  by  paragraph 
6c,  then  a  waiver  approval  is  required  from  HQDA,  DISC4 
(SAIS-ADO)  to: 

(1)  Develop  Kemy  software  In  another  cooputer  langut.ge. 

(2)  Acquire  off-the-shelf  software,  Inplemented  in  other 
than  Ada,  which  requires  Government  maintenance  or  modification 
of  more  than  one-third  of  the  total  system  software. 

(3)  Znplement  a  system/subsystem  in  a  46L. 
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(4)  Develop  an  Axiay  system,  with  severe  time  and/or  size 
constraints.  In  which  the  machine  level  to  Ada  source  code  ratio 
exceeds  15  percent  or  the  total  machine  language  code  exceeds 
10,000  lines. 

e.  Zn  all  Instances,  however,  anyone  requesting  a  waiver  must 
demonstrate  that  the  software  strategy  Is  more  cost-effective  or 
more  operationally  effective  over  the  system  life  and  must 
Include  a  statement  of  maintainability  from  the  responsible 
software  maintalner . 

7 .  Waivers 

a.  with  the.  exception  noted  In  paragraph  €c,  a  waiver  must  be 
obtained  to  develop  any  non-Ada  software. 

b.  Justification  must  address  the  following  Issues: 

(1)  The  waiver  request  will  provide  adequate  technical 
description  to  address  limitations,  documentation,  portability, 
maintainability,  and  usability  of  the  proposed  software  language 
or  package . 

(2)  The  waiver  request  will  provide  coiqplete  life-cycle 
economic  rationale  for  both  Ada  and  the  requested  language.  For 
tactical  systems,  intelligence  systems,  and  embedded  weapon 
systems,  the  waiver  request  must  also  Include  a  risk  analysis 
that  addresses  technical  performance  and  schedule  impact. 

c.  A  waiver  request  for  all  new  Initiatives  aust  be  approved 
prior  to  Milestone  Z  approval.  Prototypes  may  use  advanced 
software  technology  (such  as  4GLs)  In  accordance  with  paragraph 
6c  (2) .  However,  sunk  costs  for  a  non-Ada  prototype  will  not  be 
considered  justification  for  a  waiver. 

d.  An  existing  system  undergoing  modification,  as  defined  In 
paragraph  6a,  must  have  received  a  waiver  prior  to  system 
redevelopment  regardless  of  the  cost. 

e.  The  long-term  costs  of  supporting  programmers, 
environments,  and  software  code  for  diverse  languages  will  be 
closely  scrutinized  when  waivers  are  considered. 

f .  Waivers  will  apply  only  to  the  specified  system  or 
subsystem  Identified. 

g.  Waiver  processing  procedures  are  as  follows: 

(1)  When  there  Is  a  PEO/PM  structure  in  place  the  waiver 
request  will  be  submitted  from  the  PM  through  the  PEO  (and  MACOM 
if  appropriate)  to  the  DZSC4  (SAZS-ADO) .  All  requests  will  have 
a  statement  of  maintainability  from  the  applicable  Life  Cycle 
software  Englneerlnrr  Center  (LCSEC) ,  Software  Development  Center 
(SDC) ,  or  Government  software  engineering  organization  that  will 
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be  responsible  for  maintenance  of  the  system. 

(2)  When  there  is  no  PEO/PM  structure  in  place,  the  waiver 
request  will  be  submitted  through  the  cognizant  software  support 
center  through  the  MACOM  to  the  DISC4 . 

(3)  Nalvers  may  be  denied  at  any  level  but  can  only  be 
approved  by  the  DISC4. 

8.  Effective  date  and  iiqslementation .  This  directive  is 
effective  immediately.  MACOM  Deputy  Chiefs  of  Staff  for 
Information  Manageskent  (DCSZMs)  and  PEOs  will  forward  a  copy  of 
their  consolidated  initial/updated  Ada  inplementation  plans 
(appendix  A)  to  HQDA  (SAIS-ADO)  Washington,  DC  20310-0107  by 
1  October  1990.  Updates  to  the  Ada  Xsqklementation  Plan  are  due 
on  1  October  aimually. 
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Appendix  A 

Ada  Systems  Implementation  Plan 

1.  NACON/Xnstallation 

2 .  POC  Name/Telephone 

3.  System  Name  and  Acronym 

4.  Current  Life  Cycle  Management  Phase 

5.  System  Fielding  Data 
S.  ADP  Hardware  Used 

7.  Coaputer  Operating  System 

8.  Software  Languages  Used  by  Subsystem<s)  Including  Support 
Software 

a .  Name 

b.  Lines  of  Code 

c.  Percent  of  System 

9.  Database  Management  System  (DBMS)  Used 

10.  DBMS  Interface  Technique 

11.  Program  Design  Language/Zsplementation  Language 

12.  Project  ^proval  Documentation  (Coa^uter  Resources  Management 
.'Ian  (CRMP),  Acquisition  Plans,  and  sc  on,  with  status) 

13.  Date  Waiver  Approved  (if  applicable) 

14.  Ada  Transition  DAtes  (start  and  finish) 

15.  Planned  Upgrade  Date(s)  (for  either  hardware  or  software) 

1€.  Maintenance  Responsibility 

17.  System  Documentation  Standard  Used 

18 .  Transition  to  Ada  (narrative  e]q>lanation) 

Ada  Organizational  Implementation  Plan 

1 .  Btiman  Resources 

a.  Education  and  Training  of  Incumbent  Managesmtnt 
and  Technical  Personnel 

b.  Accession/Recruitment  of  (Qualified  Ada  Persoiuel 
e.  Ada  Support  Contractor 

2 .  Resources 

a .  Financial 

b.  Technical  Status 

(1)  Ada  Support  Environment  (including  interface 
DOD  Standard  1838) 

(2)  Interface  to  Operational  Environment 

(a)  DBMS 

(b)  Operating  System 

(c)  Graphics  Support 

Glossary 

Abbreviations 


ADP  —————  automatic  data  processing 
AJPO - Ada  Joint  Program  Office 
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ANSI  -  American  National  Standards  Institute 

CIA  -  Central  Intelligence  Agency 

CAMP  -  Conputer  Resources  Management  Plan 

DAIM - Department  of  the  Army  Information  Manager 

DBMS  -  Database  Management  System 

DCSIM  -  Deputy  Chief  of  Staff  for  Information 

Management 

OISC4  -  Director  of  Information  Systems  for  Command 

Control,  Communications,  and  Coaputers 

DOD - Department  of  Defense 

FBI  -  Federal  Bureau  of  Investigation 

4GL  -  fourth-generation  language 

I 

FIPS  -  Federal  Information  Processing  Standards 

FOA  - - — —  field  operating  agency 

HOL  — — — — —  high  order  language 

HQDA  —————  Headquarters,  Department  of  the  Am^ 

LCSEC  -  Life  Cycle  Software  Engineering  Center 

I 

MACOH  —————  major  Arwy  command 

MCCR  - - -  mission  critical  conputer  resources 

NDI - - - non-developmental  item 

PEO  -  program  executive  officer 

PM - program/project/product  manager 

POC - point  of  contact 

SDC  -  Software  Development  Center 

SQL  - — — -  structured  query  language 

STAMIS  -  Standard  hrmy  Management  Information  System 


BY  ORDER  OF  THE  SECRETARY  OF  THE  ARMY: 
MILTON  H.  HAMILTON 
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Administrative  Assistant  to  the 
Secretary  of  tha  Army 

DISTRIBUTION; 

HQDA  (DACS-ZA) 

HQDA  (SAFH) 

HQDA  (SARD) 

HQDA  (SAAA) 

HQDA  (SAIS-ZA) 

HQDA  (SAI6-ZA) 

HQDA  (DAMI-ZA) 

HQDA  (DALO-ZA) 

HQDA  (D;*  j~ZA) 

HQDA  (DAPE-ZA) 

HQDA  (DAEN-ZA) 

HQDA  (DASG-ZA) 

HQDA  (NGB-ZA) 

HQDA  (DAAR-ZA) 

HQDA  (DAJA-ZA) 

HQDA  (DACH-ZA) 

COHMANDER- IN-CHIEF 

U.S.  ARMY,  EUROPE  AND  SEVENTH  ARMY 
COMMANDERS 

EIGHTH  U.S.  ARMY 

FORCES  COMMAND 

U.S.  ARMY  MATERIEL  COMMAND 

U.S.  ARMY  TRAINING  AND  DOCTRINE  COMMAND 

U.S.  ARMY  INFORMATION  SYSTEMS  COMMAND 

U.S.  ARMY  JAPAN 

U.S.  ARMY  WESTERN  COMMAND 

MILITARY  TRAFFIC  MANAGEMENT  COMMAND 

U.S.  ARMY  CRIMINAL  INVESTIGATION  COMMAND 

U.S.  ARMY  HEALTH  SERVICES  COMMAND 

U.S.  ARMY  SOUTH 

SUPERINTENDENT,  U.S.  MILITARY  ACADEMY 
CF: 

HQDA  (SASA) 

HQDA  (SAUS) 

HQDA  (SACH) 

HQDA  (SAIL) 

HQDA  (SAMR) 

HQDA  (SAGC) 

HQDA  (SAAG-ZA) 

HQDA  (SALL) 

HQDA  (SAP A) 

HQDA  (SADBU) 

COMMANDERS 

U.S.  ARMY  MILITARY  DISTRICT  OF  WASHINGTON 
U.S.  ARMY  RECRUITING  COMMAND 
DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 
PROGRAM  EXECUTIVE  OFFICERS 
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COMHONIOITZONS 

STANDARD  ARMT  MANAGEMENT  INFORMATION  SYSTEM 

COMMAND  AND  CONTROL  SYSTEMS 

STRATEGIC  INFORMATION  SYSTEMS 

ARMAMENTS 

CHEMICAL/NUCLEAR 

ARMORED  SYSTEMS  MODERNIZATION 

AVIATION 

CCaiBAT  SUPPORT 

FIRE  SUPPORT 

AIR  DEFENSE 

INTELLIGENCE  AND  ELECTRONIC  WARFARE 
STRATEGIC  DEFENSE 
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This  mandate  was  first  included  in  the  fiscal  year  1991  appropriations  bill  (H.R.  5803)  for  the 
Department  of  Defense.  That  bill  was  signed  by  the  President  on  November  5, 1990,  and  became  Public 
Law  101-511.  IntheFY  1991  act,  the  section  number  and  wording  were: 


Sec.  8092.  Notwithstanding  any  other  provisions  of  law,  after  June  1,  1991,  where  cost 
effective,  all  Department  of  Defense  software  shall  be  written  in  the  programming  language 
Ada,  in  the  absence  of  special  exemption  by  an  official  designated  by  the  Secretary  of 
Defense. 


Similar  wording  was  also  included  in  the  FY  1992  appropriations  bill.  Public  Law  102-172,  enacted 
November  26, 1991.  TherCi  the  mandate  can  be  found  in  Section  8073.  The  FY  1991  appropriations  bill 
originated  in  the  House  as  H.R.  5803.  In  the  version  reported  out  of  the  House  and  sent  to  the  Senate, 
this  section  (originally  numbered  Sec.  8084)  had  not  contained  the  proviso  "where  cost  effective":  as 
amended  by  the  Senate,  the  mandate  was  deleted  entirely;  when  House  and  Senate  conferees  met  to 


reconcile  differences  in  the  two  versions,  they  restored  the  mandate  with  the  "where  cost  effective"  pro¬ 
viso.  With  this  proviso,  the  mandate  was  then  a  part  of  the  final  version  of  the  appropriations  bill  passed 
by  both  houses  and  signed  by  the  President.  The  following  appeared  in  House  Report  101-822,  which 
accompanied  the  original  House-passed  version  of  H.R.  5803. 


Ada  Prograrmning  Language.  —  The  Department  of  Defense  developed  Ada  to  reduce  the 
cost  of  development  and  support  of  software  systems  written  in  the  hundreds  of  languages 
used  by  the  DOD  through  the  early  1980s.  Beside  the  training  economies  of  scale  arising 
from  a  common  language,  Ada  enables  software  cost  reduction  in  several  other  ways:  (1)  its 
constructs  have  been  chosen  to  be  building  blocks  for  disciplined  software  engineering;  (2)  its 
internal  checking  inhibits  errors  in  large  systems  lying  beyond  the  feasibility  of  manual 
checking;  and  (3)  its  separation  of  software  module  interfaces  from  their  implernentattons 
facilitates  and  encourages  reuse  of  already-built  and  tested  program  parts.  While  each  of 
these  advantages  is  important,  Ada’s  encouragement  of  software  engineering  is  ftmdamental. 
Software  practitioners  increasingly  believe  the  {^plication  of  engineering  disciplines  is  the 
only  currently-feasible  avenue  toward  controlling  unbridled  software  cost  escalation  in  ^er- 
larger  and  mote  complex  systems.  In  March,  1987,  the  Deputy  Secretary  of  Defense  rnan- 
dated  use  of  Ada  in  DOD  weapons  systems  and  strongly  recommended  it  for  other  DOD 
applications.  This  mandate  has  stimulated  the  development  of  commercially-available  Ada 
compilers  and  support  tools  that  are  fully  responsive  to  almost  all  DOD  requirements.  How¬ 
ever,  there  are  still  too  many  other  languages  being  used  in  the  DOD,  and  thus  the  cost 
benefits  of  Ada  are  being  substantially  delayed.  Therefore,  the  Committee  has  included  a  new 
general  provision.  Section  8084,  that  enforces  the  DOD  policy  to  make  use  of  Ada  mandatory. 
It  will  remove  any  doubt  of  full  DOD  transition  to  Ada,  particularly  in  other  than  weapons 
systems  applications.  It  will  stimulate  DOD  to  move  forward  quickly  with  Ada-based 
software  engineering  education  and  cataloguingfteuse  systems.  In  addition,  U.S.  and  com¬ 
mercial  users  have  already  expanded  tremendously  the  use  of  Ada  and  Ada-related  technol¬ 
ogy.  The  DOD,  by  extending  its  Ada  mandate,  can  leverage  off  these  commercial  advances. 
Navy  Ada  is  considered  to  be  the  same  as  Ada  for  the  purposes  of  this  legislation,  and  the 


Copyright  1992.  DT  Research  Institute.  All  rights  assigned  to  the  U.S.  Government  (Ada  Joint  Program  0£5ce).  Permission  to 
reprint  this  flyer,  in  whole  or  in  part,  is  granted,  provided  the  AdalC  is  acknowledged  as  the  source.  If  this  flyer  is  reprinted  as 
part  of  a  published  document,  please  send  a  courtesy  copy  of  the  publication  to  AdalC,  c/o  IIT  Research  Institute,  4600  Forbes 
Boulevard  Lanham,  MD  20706-4320.  The  AdalC  is  sponsored  by  the  Ada  Joint  Program  Office. 
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term  Ada  is  oUieiwise  defined  by  ANSI/MIL-STD-1815.  The  Committee  envisions  that  the 
Office  of  the  Secretary  of  Defense  \vill  administer  the  general  provision  in  a  manner  that 
prevents  disruption  to  weapon  systems  that  are  well  into  development.  The  Committee 
directs  that  applications  using  or  currently  planning  to  use  the  Enhanced  Modular  Signal  Pro¬ 
cessor  (EMSP)  be  exempted  from  mandatory  use  of  Ada  as  a  matter  of  policy. 
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On  July  9, 1991,  the  Air  Force  released  to  the  public  a  report  of  a  business  case  they  conducted  to 
determine  under  what  circumstances  a  waiver  to  the  DoD  Ada  requirement  might  be  warranted  for  use  of 
C++,  particularly  in  DoD’s  Corporate  Information  Management  (CIM)  program.  The  report  is  titled, 
"Ada  and  C++:  A  Business  Case  Analysis." 

Since  its  release  the  report  has  received  a  great  deal  of  publicity  in  various  newspapers  and  journals. 
The  information  that  foUows  was  excerpted  from  remarks  made  by  Mr.  Lloyd  K.  Mosemann,  II  Deputy 
Assistant  Secretary  of  the  Air  Force  (Communications,  Computers,  and  Logistics),  at  a  press  conference 
held  July  9, 1991. 

I.  Introduction 

There  has  never  been  any  intention  to  question  DoD’s  commitment  to  Ada,  but  only  to  identify 
when  waivers  for  C++  might  be  warranted.  This  business  case  will  support  the  development  of  DoD  pro- 
gratruning  language  policy  for  information  systems  and  C3  systems. 

I  might  say  at  the  outset  that  language  comparison  is  not  merely  a  scientific  issue:  it  evokes  strong 
emotions  as  well,  in  that  to  a  certain  extent  people  adopt  "favorite"  languages  for  reasons  other  than 
purely  dispassionate  analysis,  much  as  one  mi^t  not  be  able  to  explain  why  he/she  roots  for  the  Chicago 
Cubs  or  drinks  Coke  rather  than  Pepsi.  The  task  is  also  rendered  difficult  because  there  are  yet  no  well- 
established  and  standard  methods  for  conducting  such  comparisons.  For  these  reasons,  we  endeavored  to 
make  our  study  as  quantitative  as  possible,  asking  the  best  experts  we  could  6nd  to  use  a  variety  of 
methods  that  have  historically  been  used  for  business  analysis  in  such  tasks.  We  felt  that  by  using  a 
variety  of  methods  and  comparing  their  results,  we  would  avoid  the  skewing  that  might  result  from  the 
sole  use  of  a  single  method. 

In  our  business  case,  therefore,  several  different  approaches  were  undertaken  to  identify,  from  a 
business  perspective,  when  the  life  cycle  cost  effectiveness  of  C++  might  be  greater  than  that  of  Ada. 

•  The  first,  conducted  by  the  Institute  for  Defense  Analyses  Gf^A),  examined  quantitatively  the  avai¬ 
lability  of  tools  and  training  for  the  two  languages. 

•  The  second,  conducted  by  the  Software  Engineering  Instinite,  applied  to  this  problem  a  quantitative 
language  selection  methodology  developed  by  IBM  for  the  Fedei^  Aviation  Administration  (FAA). 

•  The  third,  conducted  by  CTA,  Inc.,  analyzed  cost  and  cost  analysis. 

•  And  the  fourth,  conducted  by  the  TRW  Corporation,  applied  a  standard  cost  model  in  depth  to  both 
languages  for  a  typical  information  systems/C3  project  (micro  analysis). 

•  In  addition,  the  Naval  Postgraduate  School  (NPS)  was  asked  to  address  the  overall  policy  issue  of 
Ada,  particularly  in  the  context  of  emerging  fourth-generation  language  (4GL)  software  technology. 

Each  of  the  substudies  reached  the  same  conclusion:  there  are  no  compelling  reasons  to  waive  the  Ada 
requirement  to  use  C++. 

Those  who  have  an  account  with  the  Defense  Technical  Information  Cemer  (DTIC)  may  purchase  "Ada  and  C-m-;  A  Business 
Case  Analysis"  fiom  DTIC,  Cameron  Station,  Alexandria,  Virginia  2314, 703/274-7633;  Order  No.  AD  A253  087;  Cost  S20.82. 
All  others  may  purchase  it  from  the  National  Technical  Information  Service  (NTIS),  U.S.  Department  of  Commerce,  S82S  Port 
Royal  Road,  Springfield,  Virginia  22161, 703/487-4600;  Order  No.  AD  A253  087;  Cost  $43.00. 
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The  business  case  analysis  v  as  directed  at  information  systems  and  C3  systems.  However,  there  is 
no  reason  to  believe  the  results  would  differ  for  computer  programs  embedded  in  weapons  systems. 

Let  me  now  summarize  for  you  the  salient  quantitative  results  of  each  study,  and  I  think  you  will 
understand  more  fully  how  we  arrived  at  our  conclusion. 

II.  Substudy  Results. 

A.  Tools,  Environments,  and  Training:  IDA  Substudy. 

The  Institute  for  Defense  Analyses  GDA)  collected  and  analyzed  information  on  the  market  availa¬ 
bility  of  commercial-  off-the-shelf  products  a\'ailable  from  U.S.  sources  for  Ada  and  C-h-  compilers, 
tools,  education,  and  training.  The  study  provided  a  large  quantity  of  demographic  data.  For  example, 
there  are  28  companies  located  in  the  U.S.  that  have  Ada  compilers  with  currently  validated  status;  1 8 
vendors  offer  C-h-  compilers.  The  Ada  compiler  vendors  are  more  likely  to  have  been  in  business  five 
years  or  more.  Ada  "v^idation"  is  more  rigorous  than  that  of  other  high  order  languages:  only  Ada  is 
monitored  and  approved  for  conformity  to  a  standard,  without  supersets  or  subsets,  by  a  government- 
controlled  process.  By  contrast,  no  validation  or  even  a  standard  of  any  kind  exists  for  C-h-,  although  a 
standard  by  1994  is  expected. 

Both  languages  are  supported  on  PCs  and  workstations.  Ada  is  also  supported  on  mainframes.  Ada, 
but  not  C-H-,  has  cross  compilation  systems. 

Ada  is  supported  with  program  engineering  tools.  Compiler  vendors  provide  a  rich  set.  Code  gen¬ 
erators  exist  for  Ada  but  none  so  far  for  C-h-.  There  is  considerable  variability  among  C-h-  products  in 
language  features  supported  and  libraries  provided. 

Ada  is  taught  in  43  states  at  223  universities  and  13  DoD  installations.  C-h-  is  taught  in  four  states 
at  four  universities  and  no  DoD  installations.  There  are  more  Ada  than  C-h-  courses  available.  The  cost 
of  training  is  about  equal,  but  Ada  course  variety  is  wider. 

B.  Faceted  IBM  Language  Seleaion  Methodology:  SEI  Substudy. 

The  Federal  Aviation  Administration  G^AA)  contracted  with  IBM  in  the  mid-1980s  to  evaluate  high 
order  languages  for  use  on  its  Advanced  Automation  System  (AAS)  Program.  In  response,  IBM 
developed  a  foimal,  quantitative  faceted  methodology  comparing  48  language  features  (criteria)  in  six 
categories.  This  IBM  study  concluded  that  use  of  Ada  was  "in  the  ultimate  best  interest  of  the  AAS  pro¬ 
gram  and  its  goals,  and  that  warrants  coping  with  the  temporary  risks^roblems  that  loom  large  in  the 
near  term  in  order  to  reap  the  significant  benefits^iayoffs  over  the  long  tenn." 

Using  this  same  methodology  for  each  of  the  48  criteria,  the  Software  Engineering  Institute  (SEI) 
evaluated  Ada  and  C-h-  for  application  in  information  systems/C3  systems.  The  original  FAA  weighted 
scores  for  the  six  criteria  categories  were  as  shown  in  this  matrix: 
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Category 

Max. 

Ada 

C 

Pascal  JOVIAL  FORTRAN 

Ct^ability 

16.7 

6.1 

9.6 

10.4 

7.6 

3.9 

Efficiency 

16.4 

8.0 

11.8 

10.8 

11.0 

11.1 

Availability/Reliability 

22.6 

21J 

11.6 

14.5 

15.6 

10.3 

Maintainability/Extensibility 

17.4 

14.0 

10.2 

12.2 

6.8 

8.3 

Lifecycle  cost 

11.3 

8.2 

7.4 

7.8 

4.9 

5.2 

Risk 

15.6 

8.8 

8.9 

7.6 

9.6 

8.2 

Total 

100.0 

76.6 

59.5 

63.3 

55.5 

47.0 

The  1991  weighted  scores  for  the  six  criteria  categories  were: 


Category 

Max. 

Ada 

C++ 

Capability 

16.7 

15.3 

11.3 

Efficiency 

16.4 

10.7 

10.9 

Availability/Reliability 

22.6 

19.1 

12.6 

Maintainability/Extensibility 

17.4 

13.6 

11.4 

Lifecycle  cost 

11.3 

8.4 

8.0 

Risk 

15.6 

11.7 

9.8 

Total 

100.0 

78.8 

63.9 

In  1985  Ada  was  considered  considerably  more  capable  than  C.  Today,  the  SEI  study  fou:.*'  iiicie  is  still 
a  significant  difference  between  Ada  and  C++,  C’s  successor.  The  relative  effic'er.wy  of  Ada  has 
improved  markedly;  Ada  still  scores  significantly  higher  in  availability/reliability;  the  Ada  advantage  in 
maintainability/exu.isibility  persists;  and  from  a  position  of  parity  in  1985,  Ada  has  attained  in  1991  a 
significant  advantage  over  C++  in  lowered  risk. 

An  attachment  lists  numerous  major  Ada  information  systems/C3  systems.  It  is  not  widely  appreci¬ 
ated  that  such  extensive  use  is  now  being  made  of  Ada:  in  fact,  the  Ada  9X  Project  Office  reports  that  the 
U.S.  Ada  market  excluding  training,  services,  and  government  research/development,  now  exceeds  $1 
billion. 

C.  Macro  Cost  Analysis:  CTA  Substudy. 

CTA  compiled  and  compared  available  productivity  and  cost  data  of  Ada  and  C++.  Much  of  their 
data  comes  from  Reifer  Consultants’  extensive  database,  one  of  the  best,  largest,  and  most  current  pro¬ 
gramming  language  cost  databases  now  available. 

Average  productivity  across  the  four  domains  for  which  data  exists  (environmentAools,  telecom¬ 
munications,  test  (with  simulators)  and  other)  for  both  Ada  and  C++  projects  is  shown  in  this  matrix. 
Note  the  productivity  advantage  for  Ada: 
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Productivity 

(SLOC/MM) 

Number  of 
Data  Points 

Norm  (all  languages) 

183 

543 

Average  (Ada) 

210 

153 

Average  (C++) 

187 

23 

First  project  (Ada) 

152 

38 

First  project  (C++) 

161 

7 

The  C++  project  data  reflected  information  on  23  projects  taken  from  seven  Arms  who  had  been  using 
C++,  Unix,  and  object-oriented  techniques  for  over  2  years.  All  projects  were  new  developments.  Appli¬ 
cation  size  ranged  from  25  to  500  KSLOCs  (thousand  source  lines  of  code).  Average  size  was  about  100 
KSLOC. 

The  average  costs  across  the  four  domains  for  both  Ada  and  C++  projects  are  shown  in  this  matrix. 


Cost 

Number  of 

($/SLOC) 

Data  Points 

Cost  (all  languages) 

$70 

543 

Average  (Ada) 

65 

153 

Average  (C++) 

55 

23 

Typically,  the  Ada  developments  were  performed  in  accordance  with  military  standards  and  incorporated 
formal  reviews,  additional  documentation,  and  additional  engineering  support  activities  such  as  formal 
quality  assurance  (QA)  and  configuration  management  (CM).  Most  C++  projects  are  commercial  and  do 
not  extensively  incorporate  such  activities.  Additionally,  on  such  projects  developers  are  typically  inti¬ 
mately  involved  with  users,  resulting  in  considerably  less  requirements  engineering  effort.  Conse¬ 
quently,  applications  on  which  C++  is  used  are  inherently  less  costly,  so  that  the  reported  productivity 
rates  arc  favorably  skewed  toward  C++. 

The  average  error  rates  across  the  four  domains  for  both  Ada  and  C++  projects  were: 


Integration 
Error  Rates 
(Errors/KSLOC) 

FQT 

Error  Rates 
(Errors/KSLOC) 

Number  of 
Data 
Points 

Norm  (all  languages) 

33 

3 

543 

Average  (Ada) 

24 

1 

153 

Average  (C++) 

31 

3 

23 

The  integration  error  rates  include  all  errors  caught  in  test  from  start  of  integration  testing  until  comple¬ 
tion  of  software  Formal  Qualification  Test  (FQT).  The  FQT  error  rate  includes  only  those  errors  found 
during  the  FQT  process. 

A  so-called  "transition  state  analysis"  performed  by  Rcifer’s  group  indicates  that  26  of  the  38  firms 
within  the  Ada  database  had  successfully  made  the  changeover  to  effective  use  of  Ada,  while  none  of  the 
7  firms  in  the  C++  database  had  made  the  transition.  Also,  none  of  the  7  finms  were  fully  using  C++’s 
inheritance  and  other  advanced  features. 

The  standardization  maturity  of  Ada  was  found  by  the  CTA  to  be  particularly  important  While  Ada 
has  a  firm  and  well  policed  standard,  allowing  neither  supersets  nor  subsets,  it  will  be  yean  before  a 
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stable  C++  language  specification  is  established.  New  features  are  being  considered  for  the  latest  stan¬ 
dard  C++  release.  Vendors  are  likely  to  offer  their  own  enhanced  versions  of  C++  compilers  and  CASE 
tools,  complicating  portability  and  reuse. 

Finally,  the  original  arguments  for  establishing  a  single  programming  language  for  military  applica¬ 
tions  were  found  to  remain.  Common  training,  tools,  understanding,  and  standards  simplify  acquisition, 
support  and  maintenance.  The  study  concluded  that  after  maniring  for  a  decade,  Ada’s  benefits  have 
been  proven  for  all  application  classes.  Ada  projects  have  reported  15%  higher  productivity  with 
increased  quality  and  double  the  average  size.  Normalizing  these  data  to  comparable  size  projects  would 
result  in  an  expeaed  Ada  productivity  advantage  of  about  35%.  Ada  should  be  the  near  term  language  of 
choice.  C++,  the  study  felt,  still  needs  significant  maturing  before  it  is  a  low  risk  solution  for  a  large 
DoD  application. 

D.  Micro  Cost  Analysis:  TRW  Substudy. 

TRW  performed  a  tradeoff  analysis  that  generalized  recent  corporate  cost  analyses  on  a  typical 
real-world  information  systems/C3  systems  project  Their  study  defined  a  set  of  maximally  independent 
criteria,  judged  each  language  with  respect  to  those  criteria,  and  then  translated  those  judgments  into  cost 
impacts  to  emphasize  the  importance  of  each  criterion  from  a  lifecycle  cost  perspective.  Results  were 
translated  into  perturbations  of  Boehm’s  Ada  COCOMO  cost  model. 

Rankings  of  the  two  languages  based  on  this  analysis  are  shown  in  this  matrix  (0  =  no  support;  5  = 
excellent  support),  followed  by  a  total  score,  a  weighted  sum  of  the  rankings  based  on  weights  deter¬ 
mined  by  an  expert  panel: 


Category 

Ada 

C++ 

Reliable  S/W  Engineering 

4.5 

3.2 

Maintainable  S/W  Engineering 

4.4 

3.2 

Reusable  S/W  Engineering 

4.1 

3.8 

Realtime  S/W  Engineering 

4.1 

2.8 

Portable  S/W  Engineering 

3.6 

2.9 

Runtime  Performance 

3.0 

3.6 

Compile-Time  Performance 

2.3 

3.1 

Multilingual  Support 

3.1 

2.4 

OOD/Abstraction  Support 

3.9 

4.6 

Program  Support  Environment 

4.1 

2.1 

Readability  _  . 

4.4 

2.9 

Writeability 

3.4 

3.5 

Large  Scale  S/W  Engineering 

4.9 

3.3 

COTS  S/W  Integration 

2.8 

3.6 

Precedent  Experience 

3.6 

1.5 

Popularity 

2.8 

4.0 

Existing  Skill  Base 

3.0 

1.8 

Acceptance 

2.5 

3.3 

Total  Score  for  Mgt  Info  Systems 

1631 

1324 

(Ada  score  is  23%  higher) 

Total  Score  for  C3  Systems 

1738 

1401 

(Ada  score  is  24%  higher) 

The  study  concluded  that  both  Ada  and  C++  represent  improved  vehicles  for  software  engineering  of 
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higher  quality  products.  Currently,  C++  was  estimated  to  be  approximately  3  years  behind  Ada  in  its 
maturity  and  tool  support.  The  case  study  used  in  this  report  (the  Command  Center  Processing  and 
Display  System--  Replacement)  demonstrated  development  cost  advantages  for  Ada  on  the  order  of  35% 
and  maintenance  cost  advantages  for  Ada  on  the  order  of  70%  under  today’s  technologies.  In  the  far  tem 
(1994+),  the  study  felt,  this  Ada  advantage  might  erode  to  approximately  a  10%  advantage  in  develop¬ 
ment  costs  and  30%  in  maintenance  costs  for  a  typical  development  intensive  system. 

The  study  listed  the  primary  strengths  of  Ada  as  its  support  for  realtime  domains  and  large  scale  pro¬ 
gram  development.  Its  primary  weaknesses  are  its  compile-time  and  runtime  efficiency.  The  primary 
strengths  of  C++  listed  were  its  support  for  better  object  oriented  design,  support  for  COTS  integration, 
and  its  compile-time  and  runtime  efficiency.  Its  main  weaknesses  were  identified  as  its  support  for  relia¬ 
bility  and  large  scale  program  development.  In  general,  the  sfjdy  felt  Ada’s  weaknesses  to  be  solved  by 
ever-increasing  hardware  performance  and  compiler  technology  advancement.  C++  weaknesses,  on  the 
other  hand,  remain  to  be  solved  by  advances  in  its  support  environment. 

E.  Ada  Policy  Issues:  NFS  Study. 

Concurrently  with  the  preparation  of  this  Ada  and  C++  Business  Case  Analysis,  the  Naval  Postgra¬ 
duate  School  (NPS)  reported  on  policy  issues  on  the  use  of  Ada  for  Management  Iitformation  Systems. 
Their  report,  an  analysis  of  the  need  to  see  Ada  in  a  total  and  evolving  context,  is  an  important  vision 
statement  leading  from  Ada  as  the  primary  third-generation  language  (3GL)  to  its  conception  as  the  basis 
for  evolvrng  to  higher  levels  of  productivity  in  so-called  3  1/2  GL  and  4GL  environments. 

Rather  than  concentrating  on  programming  language  selection,  the  NPS  report  focuses  on  and 
argues  for  needed  advances  in  software  development  technology.  In  particular,  the  Report  contends, 
while  traditional  factors  such  as  programming  language  selection,  better  training,  and  computer-assisted 
software  engineering  (CASE)  tools  can  enhance  productivity  modestly,  a  fundamental  change  in  the 
software  development  paradigm  will  be  necessary  to  achieve  an  order  of  rnagnimde  gain.  Such  a  gain  is 
possible  through  use  of  4GLs,  languages  that  will  ultimately  enable  the  developer  to  define  the  complete 
design  of  an  application  entirely  in  the  4GL’s  own  high-level  specification  language.  The  specification  is 
then  translated  automatically  by  the  4GL  into  an  executable  program.  When  accompanied  by  a  produc¬ 
tive  development  environment,  an  evolutionary  implementation  methodology,  and  well  trained  develop¬ 
ment  teams,  the  report  asserts,  4GLs  can  provide  a  tenfold  gain  in  productivity. 

An  intermediate  step  cited  by  the  report  in  the  movement  to  4GLs  is  3  1/2  GL  programming,  a  term 
referring  to  the  extensive  use  of  CASE  tools  coupled  with  a  high  level  of  code  reuse.  The  3  1/2  GL 
approach  requires  a  strong  commitment  to  codifying  and  accrediting  code  modules,  to  the  point  where  it 
becomes  easier  and  more  desirable  to  reuse  code  than  to  rewrite  it 

Although  experience  with  4GLs  has  not  yet  been  extensive  (with  existing  experience  limited  largely 
to  specific  ftmctional  domains  such  as  financial  management  and  transaction  processing),  4GLs  are 
attractive  for  several  reasons.  One  is  their  robusmess  under  change:  changes  made  to  the  application,  for 
whatever  reason,  are  made  at  the  specification  level  and  then  re-  translated  automatically  into  executable 
code.  Another  is  the  facility  wiffi  which  they  can  be  integrated  into  tightly  knit  and  full-featured 
development  environments.  For  these  reasons,  the  report  strongly  recommends  that  the  DoD  discourage 
use  of  traditional  3GL  programming  and  take  bold  steps  to  incorporate  the  4GL  paradigm. 

Finally,  the  report  recommends  that,  given  the  importance  of  Ada  to  DoD  software,  greater  effort 
and  funding  should  be  provided  for  the  key  Ada  initiatives:  the  Ada  Technology  Improvement  Program, 
Ada  9X,  and  Ada  education  initiatives. 
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Two  issues  on  3  1/2  GLs  and  4GLs  related  to  this  business  case  were  outside  the  scope  of  the  NPS 
report.  The  first  of  these  is  that,  for  the  foreseeable  future,  state-of-the-art  limitations  will  probably  keep 
4GLs  fitim  generating  more  than  half  the  total  code  required  by  most  applications.  In  such  cases,  where  a 
substantial  amount  of  3GL  programming  will  be  required  to  complete  application  development,  use  of  a  3 
1/2  GL  approach,  rather  than  a  4GL  approach,  is  preferable. 

Another  issue  outside  the  scope  of  the  NPS  Report  was  the  evaluation  of  the  relative  merits  of  Ada 
and  C++  as  target  (output)  languages  for  4GL  application  generators.  However,  as  section  V.C  of  the 
NPS  report  points  out,  a  "standard,  stable  target  language  portable  to  a  variety  of  hardware  platforms" 
with  good  software  reuse  and  interface  definition  capabilities  is  appealing.  Although  more  study  of  the 
characteristics  desired  in  4GL  target  languages  is  warranted,  the  SEl  and  TRW  substud*es  suggest  no 
particular  advantage  of  C-h-  over  Ada  in  software  reuse  and  interface  definition,  so  there  appears  no  rea¬ 
son  to  waive  DoD’s  Ada  requirement  in  favor  of  C-h-  as  a  target  language  for  4GLs. 

HI.  Conclusions. 

All  four  substudies  which  specifically  compared  Ada  and  C-h-  (IDA,  SEI,  CTA,  TRW)  report  a 
significant  near  term  Ada  advantage  over  C-h-  for  all  categories  of  systems.  This  advantage  could  be 
eroded  as  C-h-  and  its  supporting  environments  mature  over  the  next  fcw  years.  On  the  other  hand,  as 
aggressive  overseas  Ada  irutiatives  stimulate  even  wider  domestic  Ada  interest,  as  Ada 
tools/environments  further  manire,  and  when  the  Ada  update  (Ada  9X)  is  complete,  the  balance  could  tip 
further  in  Ada’s  favor. 

Adding  to  the  case  for  Ada  is  the  fact  that  the  Ada  scoring  so  well  in  the  business  case  was  Ada’s 
1983  version,  MIL-STD-ISISA.  Just  as  C-h-  incorporates  into  C  certain  software  engineering  concepts 
already  in  Ada  (e.g.,  modularity,  strong  typing,  specification  of  interfaces),  so  f>n  Ada  update  now  under¬ 
way  will  bring  into  Ada  selected  features  now  included  in  C-h-.  This  update,  knovm  as  the  Ada  9X  Pro- 
jea,  is  tai^geted  for  completion  in  1993.  The  product  of  extensive  community  involvement  (incl  jding  the 
C3  and  MIS  communities),  Ada  9X  will  bring  to  Ada  such  improvements  as  decimal  arithmetic,  interna¬ 
tional  character  sets,  improved  input/output,  support  for  caUs  between  Ada  and  other  languages,  further 
representation  specifications,  and  inheritance^lymorphism  (popular  features  of  C-h-).  The  Ada  9X  Pro¬ 
ject  Office  lists  one  of  the  goals  of  Ada  9X  as  "to  provide  all  the  flexibility  of  C-h-  with  the  safety,  relia¬ 
bility,  and  understandability  of  Ada  83." 

At  the  same  time,  Ada  9X  has  been  designed  so  that  neither  existing  Ada  benefits  nor  performance 
will  be  lost.  For  example,  Ada  9X  inheritance  will  be  controlled  so  as  not  to  reduce  lifecycle  supportabil- 
ity.  Some  have  criticized  OOP  features  such  as  inheritance  as  potentially  dangerous  to  DOD  software 
mission  goals  (such  as  safety,  reliability,  and  dependability). 

Bjame  Stroustrup  himself,  the  originator  of  C-h-,  has  been  quoted  as  follows:  "C  makes  it  easy  for 
you  to  shoot  yourself  in  the  foot.  C-h-  makes  that  harder,  but  when  you  do,  it  blows  away  your  whole 
leg." 

In  summary,  it  is  not  possible  to  make  a  credible  case  for  the  existence  of  classes  of  "more  cost 
effective"  C-h-  systems  compared  to  Ada.  Business  cost  effectiveness  dau  colleaed  for  this  study  are 
typified  by  the  TRW  study’s  conclusion  that  Ada  provides  development  cost  advantages  on  the  order  of 
35%  and  maintenance  cost  advantages  on  the  order  of  70%.  In  terms  of  full  lifecycle  costs,  it  will  be 
some  time  before  data  exists  which  could  justify  a  cost  savings  for  C-h-.  Today,  there  is  limited  lifecycle 
data  available  for  Ada  and  almost  none  for  C-h-. 

For  the  foreseeable  future,  then,  this  business  case  shows  that  there  are  more  than  enough  reasons 
for  the  DoD  to  stick  firmly  with  Ada,  boL  for  all  high  order  language  (3GL  and  3  1/2  GL)  development 
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and  for  exclusive  use  as  a  target  language  of  4GL  application  generators  in  the  large  class  of  applications 
for  which  3GL  code  must  supplement  generated  code. 
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AdaSoft 

AdaManager/AdaQuest.  AdaMcntor  Computer  Managed  Instruction  System,  Graphical 
Modeling  System  (SL-GMS).  AdaSoft  Graphical  User  Interface  (GUI),  AdaSoft  Textual 
User  Interface  (TUI). 

AdaSoft,  Inc.,  8750-9  Cherry  Lane,  Laurel,  MD  20707;  Voice:  (301)  725-7014;  FAX: 
(301)725-0980. 

AETECH 

Ada  Workstation  Environment  (AWE),  XAda  APSE. 

AETECH,  5841  Edison  Place,  Suite  !10.  Carlsbad,  CA  92008;  Voice:  (619)  431-7714; 
FAX:  (619)431-0860. 

Alsys 

Ada  compilers  for  a  variety  of  platforms. 

Alsys,  Inc.,  67  S.  Bedord  St.,  Burlington,  MA  01803-5152;  Voice:  (617)  270-0030;  FAX: 
(617)270-6882. 

Cadre  Technologies 

Teamwork  (software  engineering  tool  set). 

Cadre  Technologies,  222  Richmond  Street,  Providence,  RI  02903;  Voice:  (401)  351- 
CASE;  FAX;  (401)  351-7380. 

Caine,  Farber  &  Gordon 

PDL/81,  a  program  design  language  which  aids  in  the  design  and  documentation  of 
software.  It  is  available  for  DOS,  UNIX,  and  VAX  platforms. 

Caine,  Farber  &  Gordon,  Inc.,  1010  East  Union  Street,  Pasadena,  CA  91106r,  Voice:  (800) 
424-3070;  Voice;  (818)449-3070;  FAX:  (818)440-1742. 

Dynamics  Research  Corporation 
AdaMat. 

Dynamics  Research  Corporation,  60  Frontage  Road,  Andover,  MA  01810;  Voice:  (800) 
522-7321. 

EVB  Software  Engineering 

Complexity  Measurement  Tool  (CMT),  GRAMMI  (interface  builder). 

EVB  Software  Engineering,  5303  Spectrum  Drive,  Frederick.  MD  21701;  Voice:  (301) 
695-6960;  FAX:  (301)  695-7734. 

Fastrak  TVaining 

Ada  training  and  consulting. 

Quarry  Park  Place,  Suite  300,  9175  Guilford  Road.  Columbia,  MD  21046-1802;  Voice: 
(301)  924-0050;  FAX:  (301 )  924-3049. 

Idaho  National  Engineering  Laboratory 
AdaSAGE. 

Idaho  National  Engineering  Laboratory.  EG&G  Idaho,  Inc.,  Special  Applications  Unit,  P. 
0.  Box  1625,  Idaho  Falls,  ID  83415-1609;  Voice:  (208)  526-0656. 
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Products: 
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Company: 

Products: 

Address: 


Company: 

Products: 

Address: 


Interactive  Development  Environments 

Software  Through  Pictures  (Ada  development  environment). 

Interactive  Development  Environments  595  Market  Street,  10th  Floor,  San  Francisco,  CA 
94105;  Voice:  (800)  888-lDEl;  Voice:  (415)  543-0900;  FAX:  (415)  543-0145. 

Irvine  Compiler  Corporation 

ICC  Ada,  an  Ada  compiler  for  the  HP  90(X)  Models  300, 400,  700,  and  800,  as  well  as  a 
number  of  cross  compilers. 

Irvine  Compiler  Corporation,  34  Executive  Park,  Suite  270,  Irvine,  CA  92714;  Voice: 
(714)  250-1366;  FAX:  (714)250-0676;  E-mail:  jkohli<a)irvine.com. 

Meridian  Software  Systems 

The  AdaVantage  compiler  for  PCs  and  some  UNIX  workstations. 

Meridian  Software  Systems,  10  Pasteur  St.,  Irvine,  CA  92718;  Voice:  (800)  221-2522; 
Voice:  (714)  727-0700;  FAX:  (714)  727-3583. 

R.  &  R.  Software 
Ada  compilers  for  PCs. 

R.  &  R.  Software,  Inc.,  P.  O.  Box  1512,  Madison,  WI  53701;  Voice:  (800)  722-3248; 
Voice:  (608)  244-6436. 

Rational 

The  Rational  Environment,  Rational  Rose. 

Rational,  3320  Scott  Boulevard,  Santa  Qara,  CA  95054-3197;  Voice:  (408)  496-3600; 
FAX:  (408)  496-3636. 

P.  P.  Texel  &  Company 
Ada  training  and  consulting. 

Victoria  Plaza,  Building  4,  Suite  9,  615  Hope  Road,  Eatontown,  NJ  07724;  Voice:  (908) 
922-6323. 

Verdi)  Corporation 

self-hosted  compilers  (VADSSelO.  cross  compilers  (VADSCross),  and  Ada  Programming 
Support  Environment  (V4DS  APSE). 

Vetdix  Corporation,  14130-A  Sullyfield  Circle,  Chantilly,  VA  22021;  Voice:  (703)  318- 
5800. 
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Organization:  ACM  Special  Interest  Group  on  Ada  (SIGAda) 

Synopsis:  ACM,  founded  in  1947,  is  the  oldest  of  association  for  computing  professionals.  It  spon¬ 

sors  a  number  of  special  interest  groups  (SIGs)  of  which  SIGAda  is  one.  SIGAda  pro¬ 
motes  interest  in  and  study  of  the  Ada  programming  language.  Its  monthly  publication  is 
Ada  Letters  ($20/year  for  ACM  members,  $42/year  others). 

POC  Mark  C:rhaiidt,  ESL,  Inc.,  495  Java  Drive,  MS  M507,  Sunnyvale,  CA  94088-3510; 

VOICE:  v408)  752-2459;  E-mail;  gerhardt<3)ajpo.sei.cmu.edu. 


Organization;  Ada  Joint  Program  Office  (AJPO) 

Synopsis:  The  Ada  Joint  Program  Office  (AJPO)  was  formed  in  December  1980.  It  is  the  principal 

agent  for  development,  support,  and  distribition  of  tools,  common  libraries,  and  coordina¬ 
tion  of  Ada.  The  AJPO  coordinates  all  Ada  efiforts  within  the  DoD  to  ensure  the  compati¬ 
bility  with  the  requirements  of  other  Services  and  DoD  agencies  to  avoid  duplicative 
efforts  arid  to  maximize  sharing  of  resources.  The  AJPO  has  the  responsibility  for  manag¬ 
ing  DoD  s  effort  to  implement,  introduce,  and  provide  life-cycle  support  for  the  Ada  pro¬ 
gramming  language.  The  AJPO  maintains  the  language  standards,  oversees  the  validation 
I  effort,  and  coordinates  DoD  activities  with  respect  to  training  and  education.”  [28] 

POC  John  Solomond,  The  Ada  Joint  Program  Office,  The  Pentagon,  Room  3E1 14,  Washington, 

DC  20301-3080;  Voice:  (703)  614-0208;  E-mail:  solomond@ajpo.sei.cmu.edu. 

Organization:  Software  Engineering  Institute  (SEI) 

Synopsis:  “The  Software  Engineering  InsUtute  (SEI)  is  a  federally  funded  research  and  development 

center  sponsored  by  the  Department  of  Defense  through  the  Defense  Advanced  Research 
Projects  Agency  (DARPA).  The  SEI  contract  was  competitively  awarded  to  Carnegie 
Mellon  Umversity  in  December  1984.  It  is  staffed  by  approximately  250  technical  and 
:  sui^rt  people  ftoni  industry,  academia,  and  government.  Because  software  has  become 

I  an  increasingly  critical  component  of  U.S.  defense  systems  and  because  the  demand  for 

i  quality  software  produced  on  schedule  and  within  budget  exceeds  its  supply,  the  U.S. 

j  Department  of  Defense  established  the  Software  Engineering  Institute  with  a  charter  to 

j  advance  the  practice  of  software  engineering.  The  SEI  nission  is  to  provide  leadership  in 

j  advancing  the  state-of-the-practice  of  software  engineering  to  improve  the  quality  of  sys- 

j  terns  that  depend  on  software.  The  SEI  expects  to  accomplish  this  mission  by  promoting 

the  evolution  of  software  engineering  from  an  ad  hoc,  labor-intensive  activity  to  a  discip¬ 
line  that  is  well  managed  and  supported  by  technology.”  [18] 

*OC:  Customer  Relations,  Software  Engineering  Instimte,  Carnegie  MeUon  University  Pitts¬ 

burgh,  PA  15213-3890;  Voice;  (412)  268-5800. 


Organization:  Software  Technology  Support  Center  (STSC) 

Synopsis:  “Established  by  HQ  USAF  to  serve  as  the  focal  point  for  the  management  of  computer 

systems  support  tools,  methods,  and  environments,  for  Joint  Services  software  activities 
It  is  an  office  of  the  Ogden  Air  Logistics  Center  (AFMC!),  Hill  Air  Force  Base,  Utah.”  [19] 
POC;  Software  Technology  Support  Center,  Attn:  Customer  Service,  00-ALCynSE  Hill  AFB 

UT  84056;  Voice:  (801)  777-8045;  FAX:  (801)  777-8069. 
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The  Ada  Events  Calendar  includes  information  on  upcoming  Ada  conferences,  etc.  It  lists  only 
those  programs  with  fixed  dates,  and  does  not  include  programs,  such  as  classes,  that  are  scheduled  on  a 
continuing  basis.  Note,  however,  that  many,  if  not  most,  of  the  conferences  listed  below  are  conducted 
on  an  annula  basis. 


Date; 

Event: 

Location: 

Sponsor 

Synopsis: 


POC: 


Date: 

Event: 

Location: 

Sponsor 

POC: 


October  5-7, 1992 

6th  SEI  Conference  on  Software  Engineering  Education 
Hyatt  Islandia  Hotel,  San  Diego,  California 
Software  Engineering  Institute 

The  SEI  Conference  on  Software  Engineering  Education  is  an  aimual  conference  that 
brings  together  educators  from  universities,  industry,  and  government  to  discuss  issues 
related  to  the  content,  structure,  and  delivery  of  software  engineering  education.  The 
conference  format  includes  referred  papers,  panel  discussions,  reports,  tutorials,  and 
workshop  sessions. 

Mary  EUen  Rizzo,  Software  Engineering  Institute,  Carnegie  Mellon  University,  Pitts¬ 
burgh,  PA  15213:  Tel;  412/268-3007;  FAX:  412/268-5758;  Internet:  mer@sei.cmu.edu. 

October  14-15, 1992 
ASIS  Technical  Meeting 

Institute  for  Defense  Analyses  GDA),  Alexandria,  VA 
IDA 

Qyde  Robey,  IDA,  Tel:703/845-6666. 


Date: 

Event: 

Location: 

Sponsor 

POC: 


October  14-15, 1992 
Ada  UK  International  Conference 
Britannia  International  Hotel,  London 
Ada  Language  UK,  Ltd. 

Helen  Byard,  Administrator,  Ada  UK,  P.O.  322,  York  YOl  3GY,  England:  Tel:  (UK)  0904 
412740;  Fax;  (UK)  0904  426702. 


Date:  November  9-13, 1992 

Event:  Third  Eurospace  Ada  in  Aerospace  Symposium 

Location;  Vienna,  Austria 

POC:  Ms.  Rosy  Piet,  Eurospace,  16  bis.  Avenue  Bousquet,  F-75007  Paris,  France;  Tel:  +33-1-45 

;  55  83  53:  Fax: +33- 1-45  5 199  23. 

Date:  i  November  16-20, 1992 

Event:  1  TRI-Ada  ’92 

Location:  1  Orange  County  Convention  Center,  Orlando,  FL. 

Synopsis:  'i  The  annual  TRI-Ada  Conference  and  Exposition  is  the  Ada  community’s  largest  and  most 

\  prestigious  event  TRI-Ada,  as  its  name  implies,  reaches  out  and  brings  together  three 
1  broad  bases  in  the  Ada  community — government,  industry,  and  academia — with  a  pro- 
t  gram  that  covers  all  issues  of  importance  to  Ada  interests.  The  theme  for  this  year’s 

Copyright  1992^  IIT  Research  Institute.  All  rights  assigned  to  the  U.S.  Government  (Ada  Joint  Program  OfiSce).  Permission  to 
reprint  this  flyer,  in  whole  or  in  part,  is  granted,  provided  the  AdalC  is  acknowledged  as  the  source.  If  this  flyer  is  reprinted  as 
part  of  a  published  document,  please  send  a  courtesy  copy  of  the  publication  to  AdalC,  c/o  LIT  Research  Institute,  4600  Forbes 
Boulevard  Lanham.  MD  20706-4320.  The  AdalC  is  sponsored  by  the  Ada  Joint  Program  0£5ce. 
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conference  is,  “The  Business  of  Ada.” 

TRI-Ada  '92,  Danieli  &  O’Keefe  Associates,  Inc.,  Conference  Management,  Chiswick 
Park,  490  Boston  Post  Road,  Sudbury,  MA  01776  USA 

December  2-3, 1992 

NASA/GSFC  Software  Engineering  Laboratory  (SEL)  7th  Annual  Software  Engineering 
Workshop 

The  worfahop  is  an  annual  forum  where  software  practitioners  exchange  information  on 
the  measurement,  utilization,  and  evaluation  of  software  methods,  models,  and  tools. 
There  vnll  be  a  presentation  of  approximately  15  papers.  Papers  are  being  solicited  which 
include  the  following  topics:  experiments  in  software  development  or  management: 
experiences  wdth  software  tools,  models,  methodologies;  software  measures;  software 
reuse;  software  process  assessment  and  improvement. 

Mr.  Mark  Cashion,  NASA/Goddard  Space  Flight  Center,  Code  552,  Greenbelt,  MD 
20771,  USA;  Phone:  (301)  286-6347;  FAX:  (301)  286-9183 

December  7-1 1, 1992 

Toulouse  ’92:  Fifth  International  Conference  on  Software  Engineering  &  Its  Applications 
Toulouse,  France 

Methods,  tools,  standards,  and  organization  are  the  major  aspects  of  software  engineering 
covered  by  the  conference,  'fhe  conference  will  include  tutorials,  exhibits,  and  an  indus¬ 
trial  forum. 

Jean-Qeaude  Rault,  EC2,  269  rue  de  la  Garenne,  F-92024  Nanterre  Cedex,  France;  Tel: 
+33-1-47  80  70  00;  Fax:  +33- M7  80  66  29 

December  8-10, 1992 
STARS  '92 

Omni  Shoreham  Hotel,  Washington,  D.C. 

STARS,  Boeing,  IBM,  Paramax 

Megaprogramming  concepts,  the  firm  foundation  in  products,  relevant  successes,  and 
upcoming  plans  will  be  discussed  at  the  program.  Integration  of  process  and  reuse  within 
the  Software  Technology  for  Adaptable  Reliable  Systems  (STARS)  environment  will  be 
demonstrated.  There  will  be  exhibits  of  megaprogramming  work  in  progress  by  STARS  as 
well  as  aliiliates  and  subcontractors.  Evening  receptions  will  facilitate  networking  with 
government  and  industry  leaders. 

The  STARS  ’92  Conference  Center,  3  Church  Circle  -  Suite  194,  Annapolis,  MD  21401; 
Fax;  (410)  267-0332;  E-Mail:  STARS92-Desk@STARS.Rossyln.Unisys.com 

December  10, 1992 
Ada’s  Birthday 

March  15-18, 1993 

1 1th  Annual  National  Conference  on  Ada  Technology 

Williamsburg  Hilton  and  National  Conference  Center,  WiUiamsburg,  Virginia. 

'The  emphasis  for  this  conference  wiU  be  software  engineering,  while  continuing  to 
emphasize  Ada  as  an  important  building  block.  Papers  on  applied  aspects  of  software 
engineering  and  also  experimentation  and  research  are  being  accepted.  Presenters  must 
register  for  the  Conference. 

ANCOAT  93,  c/o  Rosenberg  &  Risinger,  1 1287  W  Washington  Blvd.,  Culver  City,  CA 
90230,  (310)  397-6338 
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March  21-23, 1993 

5th  Annual  Oregon  Workshop  on  Software  Metrics 
Silver  Falls  State  Conference  Center,  Portland  Oregon 

The  Annual  Oregon  Workshop  on  Software  was  founded  to  allow  the  interchange  of  ideas 
and  experiences  between  those  using  metrics  and  those  performing  research  in  the  area. 
Call  for  participation  is  sought  from  both  practitioners  and  researchers.  Participation  may 
consist  of  delivering  a  pape^  organizing  and  leading  a  panel  session,  or  leading  a  mini¬ 
tutorial  on  some  aspect  of  software  measurement. 

Warren  Harrison,  Center  for  Software  Quality  Research,  Portland  State  University,  Port¬ 
land.  OR  97207-0751;  (503)  725-3108;  warrerkScs.pdx.edu 

March  24-26, 1993 

Second  International  Workshop  on  Software  Reusability 
Lucca,  Italy 

EEEE  Computer  Society,  ACM  SIGSOFT 

The  themes  for  this  year’s  workshop  include  methods,  tools  and  environments,  reuse 
library  methods,  generative  approaches  to  reu.se,  constructive  approaches  to  reuse,  theoret¬ 
ical  aspects  of  reuse,  organizational  and  management  techniques  for  implementing  reuse, 
domain  analysis  methods  and  techniques.  Attendance  is  limited  to  100. 

April  18-23, 1993 

Fifth  Annual  Software  Technology  Conference 

Red  Lion  Hotel  &  Salt  Palace  Convention  Center,  Salt  Lake  City,  Utah 

U.S.  Army,  U.S.  Navy,  U.S.  Air  FOrce 

Software  -  The  Force  Multiplier 

The  program  will  include  tutorials,  vendor  demonstrations,  presentations,  and  ”birds-of-a- 
feather"  discussion  groups.  The  theme  for  this  year’s  conference  is.  “Software  -  The 
Force  Multiplier.”  General  sessions  will  address  management  information  systems, 
embedded  computers,  and  command  and  control.  Proposed  topics  for  presentations 
include  reuse,  environments,  Ada  implementation,  software  inspections,  change  manage¬ 
ment,  object  oriented  programming,  automated  software  process  enactment,  metrics,  re¬ 
engineering,  software  engineering,  software  maintenance,  DoD  software  initiatives, 
configuration  management,  and  software  process  improvement. 

Dana  Dovenbarger,  Conference  Manager,  Software  Technology  Support  Center,  00- 
ALCynSE.  HiU  AFB,  UT  84056;  Phone:  (801)  777-7411;  DSN  458-7411;  FAX:  (801) 
777-8069 

May  17-21, 1993 

ICSE:  15th  International  Conference  on  Software  Engineering 
Baltimore,  MD. 

TKF.F.  Computer  Society  Technical  Committee  on  Software  Engineering  and  ACM  Special 
Interest  Group  on  Software  Engineering. 

June  14-18. 1993 
Ada  Europe 
Paris,  France 

Ada  Europe  ’93,  AFCET,  156  Bd.  Pereire,  75017  Paris,  France 
September  18-23, 1993 
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TRI-Ada  ’93 
Seattle,  Washington 

The  theme  for  the  1993  conference  is,  "The  Management  and  Engineering  of  Software.” 


Appendix  H:  Glossary  of  Acronyms 
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ACE 

Ada  Command  Environment  (STARS) 

ACM 

Association  ior  Computing  Machinery 

ACVC 

Ada  Compiler  Validation  Capability  (AJPO) 

Ada 

Not  an  acronym 

ADA 

American  Dental  Association 

ADA 

Americans  with  Disabilities  Aa 

Ada-IC 

Ada  Information  Gearinghouse 

AdaJUG 

Ada  Joint  User’s  Group 

AlC 

Ada  Information  Gearinghouse 

ALRM 

Ada  Language  Reference  Manual 

AJPO 

Ada  Joint  Program  Office 

ANNA 

ANNotated  Ada  (Stanford  University) 

APSE 

Ada  Programming  Support  Environment 

ASAP 

Ada  Static  source  code  Analyzer  Prograin 

ASEET 

Ada  Software  Engineering  Education  and  training  Team 

ASR 

Ada  Software  Repository 

ATIP 

Ada  Technology  Insertion  Program  (AJPO) 

CAIS 

Common  APSE  Interface  Set 

CARDS 

Central  Archive  for  Reusable  Defense  Software 

CASE 

Computer  Aided  Software  Engineering 

CMU 

Camegie-Mellon  University 

COSMIC 

computer  Software  Management  and  Information  Center  (NASA) 

CREASE 

Catalog  of  Resources  for  Education  in  Ada  and  Software  Engineering 

DACS 

Data  and  Analysis  Center  for  Software 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DIANA 

Distributed  Intermediate  Attributed  Notation  for  Ada 

DID 

Data  Item  Description 

DTIC 

Defense  Technic^  Information  Center 

FIPS 

Federal  Information  Processing  Standard 

GRACE 

Generic  Reusable  Ada  Components  for  Engineering  (EVB) 

GRAMMI 

Generated  Reusable  Ada  Man  Machine  Interface  (^L) 

HOL 

High  Order  Language 

HOLWG 

High  Order  Language  Working  Group 

IDD 

Interface  Design  Document 

IEEE 

Institute  for  Electrical  and  Electronic  Engineers 

lEEECS 

IEEE  Computer  Society 

IPSE 

Integrated  Project  Support  Envirorunent 

KAPSE 

Kernel  APSE 

KIT 

KAPSE  Interface  Team 

KLOC 

Thousand  LOC 

LOC 

Lines  Of  Code 

LRM 

Language  Reference  Manual 

MAPSE 

Minimal  APSE 

MIL-STD 

Military  Standard 

NBS 

National  Bureau  of  Standards  (obsolete,  now  NIST) 

NISE 

NASA  Initiative  on  Software  Engineering 

NIST 

National  Institute  for  Standards  and  Technology  (formerly  NBS) 

NUMWG 

NUMerics  Working  Group  (SIGAda) 
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00 

Object  Oriented 

OOA 

Object  Oriented  Analysis 

OOD 

Object  Oriented  Design 

OOP 

Object  Oriented  Programming 

OOSD 

Object  Oriented  Stnictured  Design 

PCTE 

Portable  Common  Tool  Environment  (ESPRIT) 

PDL 

Program  Design  Language 

PIWG 

Performance  Issues  Woricing  Group  (SIGAda) 

RADC 

Rome  Air  Development  Center 

RIACS 

Research  Institute  for  Advanced  Computer  Science  (NASA) 

SAME 

SQL  Ada  Module  Extension 

SDD 

Software  Design  Document 

SE 

Software  Engineering 

SEI 

Software  Engineering  Institute  (Carnegie  Mellon  University) 

SGML 

Standard  Generalized  Markup  Language 

SIGAda 

Special  Interest  Group  on  Ada  (ACM) 

SIGPLAN 

Special  Interest  Group  on  Programming  LANguages 

SIGSOFt 

Special  Interest  Group  on  SOFTware 

SQA 

Software  Quality  Assurance 

SJPO 

STARS  Joint  Program  Office 

STARS 

Software  Technology  for  Adaptable  Reliable  Systems 

STSC 

Software  Technology  Support  Center 

VADS 

Verdix  Ada  Development  System  (Verdix) 

WADAS 

Washington  Ada  Symposium 
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Describes  the  final  report  of  the  Distributed  Ada  DEMonstrated  (DIADEM)  project,  which  studied 
the  problems  and  developed  solutions  for  using  Ada  to  program  real-time,  distributed  control  sys¬ 
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195  pp.  aSBN:  0-521-36154-0;  $32.50) 

Identifies  and  resolves  issues  related  to  Ada  usage  and  promotes  effective  use  of  Ada  in  general  pro¬ 
gramming,  design  practice,  and  in  embedded  computer  systems.  Contains  15  case  studies  that  cover 
five  general  areas  of  the  Ada  language:  naming  conventions,  types,  coding  paradigms,  exceptions 
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003350-1;  $39.95) 

Presents  approximately  8,(XX)  lines  of  full  coding  in  .^da  along  with  functions  which  include 
backward-chaining  expert  systems  shells  forward  chaining  expert  systems  shells  and  an  ATN  natural 
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Discusses  Ada  using  a  tutorial  style  with  numerous  examples  and  exercises.  Assumes  readers  have 
some  knowledge  of  the  principles  of  programming.  Covers  the  following:  Ada  concepts,  lexical 
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exceptions  advanced  types,  numerics  types,  generics  tasking,  external  interfaces. 
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aSBN:  0-208-02119-1;  $23.50) 

Details  the  life  of  Ada  Byron,  her  training  in  mathematics,  her  tumultuous  relationship  witi;  her 
mother  and  her  contribution  to  the  study  of  science. 
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cations  and Esperience,  ACM  Press,  New  York,  1989.  (ISBN;  0-201-50018-3) 
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ence,  Springer- Verlag,  Berlin,  1980.  630  pp.  GSBN:  0-387-102833;  $31.00Arade) 

Describes  the  Ada  programming  language,  discusses  compiler  development  and  provides  a  formal 
definition  of  Ada. 

G.  BCXX:h,  Object  Oriented  Design  with  Applications,  Benjamin-Cummings,  Menlo  Park,  California, 
1991,  aSBN;  0-8053-0091-0) 

Offers  guidance  for  constructing  object-oriented  systems  and  provides  a  description  of  object- 
oriented  design  methods.  Includes  examples  drawn  ffom  the  author’s  experience  in  developing 
software  systems  and  five  application  projects. 

G.  BoeXTH,  Software  Engineering  with  Ada,  Benjamin-Cummings,  Menlo  Park,  California,  1988.  580  pp. 
aSBN;  0-8053-0604-8;  $31.95) 

Introduces  Ada  from  a  software  engineering  vantage.  Addresses  the  issues  of  building  complex  sys¬ 
tems.  Includes  new  features  in  this  second  version:  a  more  thorough  introduction  to  Ada  syntax  and 
semantics,  an  updated  section  on  object-oriented  techniques  to  reflect  the  current  state  of  knowledge 
and  improved  examples  that  illustrate  good  Ada  style  for  production  systems  development. 

G.  BOOCH,  Software  Components  With  Ada:  Structures,  Tools,  and  Subsystems,  Benjamin-Cummings, 
Menlo  Park,  California,  1987.  635  pp.  GSBN:  0-8053-0609-9;  $35.50yipaper) 

Catalogs  reusable  software  components  and  provides  examples  of  Ada  programming  style.  Presents 
a  study  of  data  structures  and  algorithms  using  Ada. 

F.  BOTT,  ED.,  Ada  Yearbook  1991,  Van  Nostrand  Reinhold,  New  York,  1991.  GSBN:  0442-30836-1; 
$54.95/trade) 

D.  BOVER,  Introduction  to  Ada,  Addison- Wesley,  Reading,  Massachusetts,  1991.  (ISBN:  0-201-50992- 
X;  $30.25Arade) 

D.  L,  BRYAN  AND  G.  MENDAL,  Exploring  Ada:  Volume  1,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey, 
1990.  aSBN;  0-13-295684-5;  $34.00/text)  (See  Volume  2  under  Mendal) 
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Describes  Ada’s  type  model,  statements,  packages  and  subprograms.  Includes  programming 
features  such  as  information  hiding,  facilities  to  model  parallel  tasks,  data  abstraction,  and  software 
reuse. 

R.  BRYANT  AND  B.  W.  Vaget,  EDS.,  Simulation  in  Strongly  lyped  Languages:  Ada  Pascal,  Simula,  SCS 
Simulation  Series,  13,  Society  for  Computer  Simulation,  San  Diego,  California,  1984.  (ISBN:  0- 
317-05019-2;  $36.00/trade) 

R.  J.  BUHR,  Practical  Visual  Techniques  in  System  Design  with  Applications  to  Ada,  Prentice-Hall, 
Englewood  Cliffs,  New  Jersey,  1990.  533  pp.  GSBN:0-13-880808-2;  $43.20/casebound) 

Offers  a  personal  statement  on  how  to  use  visual  techniques  to  organize  one’s  thinking  during  tlie 
design  process. 

R.  J.  BUHR,  System  Design  with  Ada,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1984.  256  pp.  GSBN: 
0-13-880808-2;  $48.00  paperback)  (ISBN;0- 13-88 1623-9;  S55.P0/text) 

Stresses  aspects  of  Ada  important  for  desigrt.  Aims  numerous  examples  of  notations  at  teaching, 
learning,  CAD,  and  uses  in  industrial  practice.  Contains  three  divisions:  !)  provides  a  top  down 
overview  of  the  design  features  of  Ada;  2)  develops  the  design  notation  and  provides  a  tutorial  on 
the  design  process  using  simple  examples:  3)  treats  advanced  issues  such  as  implementing  the  X.25 
packet  switching  protocol. 

A.  BURNS,  Towards  Ada9X,  lOS  Press,  1992.  aSBN:  90-5199-075-8) 

This  book  is  a  collection  of  edited  papers  on  the  general  tiieme  of  Ada  9X.  "Two  papers  directly 
address  the  likely  language  changes.  TTie  first  of  these  is  written  by  one  of  the  Ada9X  distinguished 
reviewers.  The  second  is  by  one  of  the  team  members  that  is  actually  implemerting  the  language 
changes.  A  further  paper  describes  how  the  new  language  features  will  directly  support  the  pro¬ 
gramming  of  hard  real-time  systems.  The  book  includes  a  paper  written  by  the  chairman  of  the 
ARTEWG  group,  that  describes  the  new  release  of  the  catalog  of  interface  features  and  options  for 
an  Ada  run-time  system  (CIFO).  Other  areas  covered  include  interface  bindings,  such  as  to  SQL  or 
POSIX,  to  Ada.  ' 

A.  BURNS,  Concurrent  Programming  in  Ada,  Ada  Companion  Serie  ,  Cambridge  University  Press,  Cam¬ 
bridge,  1985.  241  pp.  aSBN;  0-521-30033-9;  $34.50/trade) 

Reports  on  Ada  tasking  offering  a  detailed  description  and  an  assessment  of  the  Ada  language  con¬ 
cerned  with  concurrent  programming. 

A.  BURNS  AND  A.  WELUNGS,  Real-Time  Systems  and  Their  Programming  Languages,  Addison- Wesley, 
Reading,  Massachusetts,  1990.  575  pp.  GSBN;  0-201-17529-0) 

Provides  a  study  of  real-time  systems  engineering,  and  describes  and  evaluates  the  programming 
languages  used  in  this  domain.  Considers  three  prograrruTiing  languages  in  detail:  Ada,  Modula-2, 
and  Occatn2. 

A.  BURNS,  A  Review  of  Ada  Tasking,  Lecture  Notes  in  Computer  Science,  262,  Springer- Verlag,  Berlin, 
1987.  aSBN:  0-387-18008-7;  $15.50) 

W.  E.  Byrne,  Software  Design  Techniques  for  Large  Ada  Systems,  Digital  Press,  Burlington,  Mas¬ 
sachusetts,  1991.  314  pp.  aSBN:  1-55558-053-X;  $45) 

Introduces  design  strategies  for  controlling  complexities  inherent  in  large  computer  programs  and  in 
software  sy.stem.c  as  groups  of  large  computer  programs  executing  concurrently.  Focuses  primarily 
on  issues  associated  with  the  design  of  software  systems  as  a  whole  rather  than  on  localized  design 
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and  coding  issues. 

P.  CA^■ERLY  AND  P.  GOLDSTEIN,  Introduction  to  Ada:  A  Top  Down  Approach  for  Programmers,  Brooks- 
Colc,  Monterey.  California,  1986.  237  pp.  (1SBN:0-5W -05 820-5;  $18.50^aper) 

Organizes  and  emphasizes  those  features  that  distinguish  Ada  from  other  programming  languages. 
Uses  a  cyclical  approach  to  the  treatment  of  many  topics.  Gives  a  brief  history  of  the  development 
of  the  Ada  language.  Introduces  the  I/O  capabilities,  procedures,  character  and  numeric  data  types 
and  subtypes,  and  the  concept  of  an  Ada  program  library.  Discusses  enumeration,  array,  record,  and 
derived  types,  and  demonstrates  how  the  package  can  be  used  to  encapsulate  data  types.  Explains 
access  types  and  applications  and  the  encapsulation  of  data  objects  in  packages.  Illustrates  how 
finite-state  machines  can  be  represented  by  packages.  Describes  the  essentials  of  tasking  and  deals 
with  blocks  and  exceptions.  Introduces  the  reader  to  private  types  types  with  discriminates,  and 
generic  units. 

G.  W.  CHERRY,  Parallel  Programming  in  ANSI  Standard  Ada.  Prentice-Hall,  Englewood  Cliffs,  New  Jer¬ 
sey.  1984.  231  pp.  (ISBN;  08359-5434-X;  $48.00Aext) 

Explores  parallel  sorting,  searching,  root  finding,  process  pipelining  object  (data)  flow  graphs, 
exception  handling,  etc.,  using  Ada. 

P.  M.  CHIRUAN,  Introduction  to  Ada,  Weber  Systems.  1985.  291  pp.  OSBN:  0-916460-42-8;  $19.95) 
Provides  a  basic  course  in  the  Ada  programming  language.  (Ada  courses  and/or  self-study) 

R.  G.  Clark,  Programming  in  Ada:  A  First  Course,  Cambridge  University  Press,  Cambridge,  1985.  215 
pp.  aSBN;  0-521-25728-X;  $47.50/trade)  OSBN;  0-521-27675-6;  $21.95/i)aper) 

Introduces  the  Ada  programming  language.  Targets  persons  without  previous  experience  in  pro¬ 
gramming.  Details  how  to  design  solutions  on  a  computer.  Concentrates  on  solving  simple  prob¬ 
lems  in  the  early  sections:  the  later  sections  explore  how  packages  can  be  used  in  constructing  large 
reliable  programs.  Emphasizes  central  features  such  as  data  types,  subprograms,  packages,  separate 
compilation,  exceptions  and  files.  ANSI/MIL-STD-I815A-1983  is  referenced  throughout  the  book. 

N.  C.  Cohen,  Ada  as  a  Second  Language,  McGraw-Hill,  New  York,  1986.  838  pp.  QSBN:  (^07- 
01 1589-3;  $36.04/lpaper) 

Explains  Ada  to  those  who  wish  to  acquire  a  reading  and  writing  knowledge  of  the  Ada  language. 
Also  a  programming  reference  source. 

R.  Conn,  Ed.,  Ada  Software  Repository  (ASR),  Zoetrope,  1990.  35  pp.  OSBN:  0-918432-78-2; 
$16.95^aper) 

Describes  how  to  use  the  Ada  Software  Repository,  which  contains  Ada  programs,  software  com¬ 
ponents,  and  educational  materials,  and  resides  on  the  host  computer  of  the  Defense  Data  Netwoilc 
(DDN). 

CULWIN,  Adla;  A  Developmental  Approach,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey. 

Intended  for  use  on  courses  which  teach  Ada  as  the  first  programming  language.  The  book  is 
designed  to  take  the  reader  from  the  basic  principles  of  progranuning  to  advanced  techniques.  This 
book  provides  a  complete  introduction  to  software  development  using  the  programming  language, 
Ada.  It  is  not  only  concerned  with  the  production  of  Ada  programs,  but  it  is  also  an  introduction  to 
the  process  of  implemenution  and  testing.  Features  include:  a  carefully  structured  tutorial  which 
includes  software  development,  design,  testing,  and  production. 
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J.  Dawes,  ET  AL,  Eds.,  Selecting  an  Ada  Compilation  System,  Ada  Companion  Series,  Cambridge 
University  Press,  Cambridge,  1990.  173  pp.  (isBN:0-521-40498-3;  $42.95) 

Presents  the  findings  of  the  Ada-Europe  specialist  group  for  compiler  assessment. 

J.  Dawes,  The  Professional  Programmers  Guide  to  Ada,  Pittman  Publishing,  Marshfield,  Massachusetts, 

1988.  aSBN:  0-273-02821-9;  SlOO.OOx) 

S.  F.  DORCHAK  and  P.  B.  Rice,  Writing  Readable  Ada:  A  Case  Study  Approach,  Heath,  Lexington,  Mas¬ 

sachusetts,  1989.  244  pp.aSBN:  0-669-12616-0;  $17.00) 

Contains  a  style  guide,  which  gives  suggestions  for  enhancing  code  readability;  devotes  a  chapter  to 
the  discussion  of  concurrency,  an  advanced  feature  of  modem  programming  languages;  a  fully 
coded  Ada  program,  along  with  a  sample  run;  a  bibliography,  which  lists  books  and  articles  about 
Ada  and  software  engineering  principles;  two  indexes,  one  devoted  exclusively  to  references  of  case 
study  modules  and  the  other  listing  important  topics  and  concepts. 

T.  F.  Elbert,  Embedded  Programming  in  Ada,  Van  Nostrand  Reinhold,  New  York,  1989.  523  pp.  (ISBN: 

(^442-22350-1;  $55.00/trade) 

Qarifies  Ada  for  the  practicing  programmer  and  for  the  advanced  engineering  or  computer  science 
student  Assumes  the  reader  has  acquired  a  certain  level  of  sophistication,  general  concepts  nor¬ 
mally  found  in  introductory  programming  texts  are  not  covered.  Also,  presumes  the  reader  is  fami¬ 
liar  with  operating  systems  and  has  a  basic  knowledge  of  some  block-stmctured  language  such  as 
PL/1  and  Pascal. 

M.  B.  FELDMAN  AND  E.B.  KOFFMAN,  Ada  Problem  Solving  &  Program  Design,  Addison- Wesley,  Read¬ 
ing,  Massachusetts,  1991.  aSBN:0-201 -5006-3/diskette)  aSBN:0-20 1-55560/trade) 

Presents  Ada  to  the  beginning  programmer  with  emphasis  on  packages.  Contains  no  dynamic  data 
structures,  pointers,  or  tasking. 

M.  B.  FELDMAN,  Dcua  Structures  with  Ada,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1985.  314  pp. 

Highlights  the  use  of  Ada  as  a  general  putpose  programming  language.  Includes  the  following: 
linked  lists,  queues  and  stacks,  graphs,  trees  hash  methods,  sorting,  etc.  Does  not  include  generics; 
it  was  written  before  compilers  could  handle  generics.  Free  software  available  from  the  author. 

A.  R.  FEUER  AND  N.  GEHANI,  Comparing  &  Assessing  Programming  Languages:  Ada,  C  &  Pascal, 

Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1984.  (ISBN:  0-13-154840-9;  $32.00/t)aper  text) 

D.  A.  FISHER,  ED.,  Ada  Language  R^erence  Manual.,  Gensoft  Coip.,  1986.  GSBN:  0-9618252-0-0; 
$12.95^aper  text) 

G.  FISHER,  ED.,  Approved  Ada  Language  Commentaries,  Ada  Letters  Series,  9,  ACM  Press,  New  York, 

1989.  aSBN:  0-89791-311-6;  $30.00/paper  text) 

B.  FORD,  ET  AL.,  Scientific  Ada,  Ada  Companion  Series,  Cambridge  University  Press,  Cambridge,  1987. 

386  pp.  aSBN:  0-521-33258-3;  $44.50/trade) 

Explores  aspects  of  the  Ada  programming  language  that  are  relevant  to  the  scientific  (i.e.,  numeric) 
community  at  large.  Concentrates  on  the  numeric  models  of  Ada  and  a  number  of  Ada-specific 
features  (e.g.,  generics).  Reviews  guidelines  for  the  design  of  large  scientific  libraries  in  Ada. 

R.  J.  Gautier  and  P.  J.  Wallis,  Software  Reuse  with  Ada,  Peregrinus  Ltd.,  Stevenage,  Hertfordshire, 
England,  1990.  205  pp.  GSBN:  0-86341-173-8) 
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Contains  three  sections:  1)  general  reuse  issues,  comprises  a  collection  of  papers  on  various  aspects 
of  Ada  software  reuse;  2)  case  studies  of  Ada  reuse  in  practice;  and  3)  Ada  Reuse  Guidelines  which 
appear  in  their  final  form  in  this  section. 

N.  GehaNI,  Ada:  An  Advanced  Introduction,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1989.  280  pp. 
aSBN:  0-13-004334-6  $32.40y^aper) 

Introduces  advanced  problem-solving  in  Ada.  Emphasizes  modular  programming  as  good  program¬ 
ming  practice. 

N.  GEHANI,  Ada:  Concurrent  Programming,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1984.  261  pp. 
OSBN:  0-13-00401 1-8;  out  of  print) 

Offers  a  large  collection  of  concurrent  algorithms,  expressed  in  terms  of  the  constructs  provided  by 
Ada,  as  the  support  for  concurrent  computation.  Explains  the  concurrent  programming  facilities  in 
Ada  and  shows  how  to  use  them  effectively  in  writing  concurrent  programs.  Surveys  concurrent 
programming  in  other  languages,  and  discusses  issues  specific  to  concurrent  programming  facilities 
in  Ada. 

N.  GehaNI,  Unix  Ada  Programming,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1987.  3 10  pp.  (ISBN: 
0-13-938325-5;  $34.00/paper) 

Focuses  on  the  novel  aspects  of  the  Ada  language  and  explains  them  by  many  examples  written  out 
in  full.  Examines  the  interesting  differences  between  the  Ada  language  and  dther  programming 
languages.  Also,  notes  the  similarities  between  Ada,  Pascal,  C,  Pl/I,  and  Fortran,  i 

i 

G.  Gilpin,  Ada:  A  Guided  Tour  and  Tutorial,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1987.  410 
pp.aSBN:  0-13-73599-0;  $21.95/paper)  | 

Reports  on  the  developments  in  control  structures,  scalar  data  types  multitasking,  program  structure 
and  access  types.  | 

I 

S.  J.  Goldsack,  Ada  for  Specification:  Possibility  and  Limitations,  Ada  Companion  Series,  Cambridge 
University  Press,  Cambridge,  1986.  265  pp.  (ISBN;  0-521-30853-4;  $7.50/trade) 

Examines  the  use,  role,  features  and  purpose  of  specification  languages,  particularly  Ada,  in  a 
large-scale  software  project. 

D.  W.  Gonzalez,  Ada  Programmer's  Handbook,  Benjamin-Cummings,  Menlo  Parle,  California,  1991. 
aSBN:  0-8053-2529-8;  $13.95yt)aper) 

D.  W.  Gonzalez,  Ada  Programmer's  Handbook  arui  Language  R^erence  Manual,  Benjamin- 
Cummings,  Menlo  Park,  California,  1991.  200  pp.  (ISBN;  0-8053-2528-X;  19.95^aper) 

Presents  information  intended  for  those  professionals  transitioning  to  Ada.  includes  a  glossary. 

G.  GOOS,  ET  AL.,  Diana:  An  Intermediate  Language  for  Ada,  Lecture  Notes  iu  Computer  Science, 
Springe;- Vetiag,  Berlin,  1987.  201  pp.  GSBN:  0-387-12695-3;  $20.00^aper) 

Describes  DIANA,  a  Descriptive  Intermediate  attributed  Notation  for  Ada,  which  resulted  fiom  a 
merger  of  the  properties  of  two  earlier  similar  intermediate  forms:  TCOL  and  AIDA. 

A.  HabERMANN  and  D.  E.  Perry,  Ada  for  Experienced  Programmers,  Computer  Science  Series, 
Addison- Wesley,  Reading,  Massachusetts,  1983.  480  pp.  (ISBN;  0-201-1 1481-X:  $29,25^aper) 

Offers  a  comparative  review  of  Ada  and  Pascal,  using  dual  program  examples  tc  illustrate  software 
engineering  techniques. 
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A.  N.  Habermann,  ED.,  System  Development  &  Ada,  Lecture  Notes  in  Computer  Science,  275, 
Springer- Verlag,  Beilin,  1987..  GSBN:  0-387-18341-8;  $25.70/^aper) 

S.  HEILBRUNNER,  Ada  in  Industry:  Proceedings  of  the  Ada-Europe  International  Conference,  Munich, 
June  7-9,  1988,  Ada  Companion  Series,  Cambridge  University  F*rcss,  Cambridge,  1988.  262  pp. 
aSBN:0-52 1-36347-0;  $42.50/trade) 

Provides  state  of  the  art  reports  on  the  Ada  programming  language. 

P.  Hibbard,  ET  AL.,  Studies  in  Ada  Style,  Springer- Veriag,  Berlin,  1983.  101  pp.  GSBN:  0-387-90816-1; 
$21.50yipaper) 

Presents  concepts  of  the  abstractions  embodied  in  Ada  with  five  examples:  a  queue,  a  graph  struc¬ 
ture,  a  console  driver,  a  table  handler  and  a  solution  to  Laplace’s  equation  using  multiple  tasks. 

J.  ICHBIAH,  ET  AL.,  Rationale  for  the  Design  of  the  Ada  Programming  Language,  Cambridge  University 
Press,  Cambridge,  1991.  aSBN;  0-521-39267-5;  $54.95) 

Presents  the  rationale  behind  the  design  and  development  of  the  Ada  programming  language. 

P.  I.  Johnson,  The  Ada  Primer,  McGrawi-Hill,  New  York,  1985.  (out  of  print) 

P.  I.  JOHNSON,  Ada  Applications  and  Administration,  McGraw-HiU,  New  York,  1990.  209  pp.  GSBN:  0- 
07-032627^ISBN;  $39.95yText  edition) 

Explains  how  to  ensure  the  reliable,  error-free,  cost-effective  operation  of  large  computer  systems 
with  Ada.  Updates  and  revises  earlier  edition  (first  entitled  The  Ada  Primer). 

D.  JONES,  Ada  in  Action  with  Practical  Programming  Examples.,  John  Wiley  &  Sons,  New  York,  1989. 
487  pp.  aSBN:  0-471-50747-4;  $57.95Aext)  GSBN:  0-471-60708-8;  $34.95yipapcr  text) 

Helps  Ada  progranuners  avoid  common  pitfalls  and  provides  them  with  many  reusable  Ada  routines. 
Discusses  a  variety  of  numeric  considerations  user  interfaces,  utility  routines,  and  software 
engineering  and  testing.  Provides  examples  of  Ada  code. 

H.  KAT21AN,  Jr.,  Invitation  to  Ada  (Condensed  Edition),  Petrocelli,  Princeton,  New  Jersey,  1984,  173  pp. 
(out  of  print) 

Introduces  Ada  in  terms  of  three  broad  classes  of  applicaUons;  numerical,  system  programming,  and 
real-time  programming. 

H.  KatZAN,  JR.,  Invitation  to  Ada,  Petrocelli,  Princeton,  New  Jersey,  1984.  (ISBN:  0-89433-239-2; 
$14.95A)apertext)  1 

H.  KatzaN,  Jr.,  Invitation  to  Ada  &.  the  Ada  Reference  Manual,  Petrocelli,  1982.  429  pp.  GSBN:  0- 
89433-132-9;  $34.95Aext)  J 

Calls  for  the  scientific  computing  community  to  adopt  the  Ada  programming  language.  Part  II  is  the 
Ada  Reference  Manual  1980  version.  ^ 

D.  KEEFFE,  ET  AL.,  Pulse:  An  Ada-based  Distributed  Operating  System,  APIC  Studies  in  Data  Process¬ 
ing,  26,  Academic  Press,  New  York,  1985.  (ISBN:  0-12-402979-1;  $39.95A5aper)  | 

J.  KELLER,  The  Ada  Challenge  1988:  Strategies  Risk  &  Payoffs,  Pasha  Publications,  1988.  (ISBN:  0- 
935453-22-9;  $174.00/paper) 
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B.  Krell,  Developing  -with  Ada:  Life-Cycle  Methods,  Bantam  Books.  New  York,  1992.  (ISBN  0-553- 
0909-3;  $54.95/hard  cover) 

Dr.  Krell  offers  his  opinion  on  the  key  to  using  Ada  to  its  fullest  potential:  a  tested  development 
methodology  for  implementing  real-time  Ada  systems  quickly  and  efficiently,  from  requirements 
and  code  generation  through  design  and  test.  By  applying  the  steps  outlined  in  Dr.  Krell’s  book, 
"software  engineers  can  create  real-time  systems  that  are  flexible,  integrate  easily,  perform  well,  and 
satisfy  user  needs,"  according  to  the  publisher. 

B.  KRIEG-BRUECKNER,  B.,  ET  AL,  Eds.,  Anna:  A  Language  for  Annotating  Ada  Programs,  Lecture  Notes 
in  Computer  Science,  260,  Springer- Vetlag,  Berlin,  1987.  0SBN:  0-387-17980-1;  $15.50/paper) 

H.  LEDGARD,  Ada:  A  First  Introduction,  Springer- Verlag,  Berlin,  1983.  130  pp.  GSBN:  0-540-908 14-5) 

Assumes  that  the  reader  has  experience  with  some  other  higher  order  programming  language.  Out¬ 
lines  several  key  features  of  Ada;  a  treatment  of  the  facilities  --  concept  of  data  types,  the  basic 
statements  in  the  language,  subprograms,  packages,  and  general  program  structure. 

H.  LEDGARD,  Ada:  An  Introduction,  Springer- Verlag,  Berlin,  1987.  GSBN:  0-387-90814-5;  $22.00y5paper 
text) 

P.  Lewi  and  J.  Paredaens,  Data  Structures  of  Pascal,  Algol  Sixty-Eight,  PL-1  &  Ada.  GSBN:  0-387- 
15121-4;  $49.00^aper) 

N.  Lomuto,  Problem  Solving  Methods  with  Examples  in  Ada,  Prentice-Hall,  Englewood  Cliffs.  New  Jer¬ 
sey,  1987.  176pp.  GSBN:  0-13-721325-5) 

Contains  a  collection  of  hints  on  solving  programming  problems.  Includes  examples  along  with  sec¬ 
tions  on  the  an  of  thinking,  analyzing  the  problem,  systematic  development,  looking  back,  ideas  for 
ideas,  and  case  studies. 

D.  C.  LUCKHAM,  ET  AL.,  Programming  with  Specifications:  An  Introduction  to  Anna,  a  Language  for 
Specking  Ada  Programs,  Texts  and  Monographs  in  Computer  Science,  Springer- Verlag,  Beilin, 
1990.  416  pp.  GSBN:  0-387-97254-4) 

Offers  an  in-depth  look  at  ANNA,  a  form  of  the  Ada  language  in  which  specially  marked  comments 
act  as  formal  annotations  about  the  program  to  which  they  are  attached. 

B.  LYNCH,  ED.,  Ada:  Experiences  &  Prospects:  Proceedings  of  the  Ada-Europe  International  Confer¬ 
ence,  Dublin,  1990,  Ada  Companion  &ries,  Cambridge  University  Press,  Cambridge,  1990.  GSBN: 
0-521-39522-4;  $9.50/trade) 

T.  G.  LYONS,  Selecting  an  Ada  Environment,  Ada  Companion  Series,  Cambridge  University  Press,  Cam¬ 
bridge,  1986.  239  pp.  GSBN:  0-521-32594-3  (BriUsh);  $29.95/trade) 

Provides  an  overview  of  the  Ada  Programming  Support  Environment  (APSE).  Covers  six  main 
issues  in  selecting  an  environment.  Contains  surrunaries  of  current  approaches  to  likely  problems, 
indications  of  deficiencies  in  existing  knowledge,  and  checklists  of  questions  to  ask  when  consider¬ 
ing  a  particular  environment 

J.  A.  MCDERMID  AND  K.  RffKEN,  Life  Cycle  Support  in  the  Ada  Environment,  Ada  Companion  Series, 
Cambridge  University  Press,  Cambridge,  1984.  (out  of  print) 

A.  D.  MCGETTRICK,  Program  Verification  Using  Ada,  Cambridge  University  Press,  Cambridge,  1982. 
345  pp.  GSBN;  0-521-24215-0;  $57.50/mde)  GSBN:  0-521-28531-3;  $29.95y)paper) 
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Discusses  such  topics  as  correctness  of  nonbranching  programs  invariants  and  termination  proofs 
via  well  formed  sets,  elementary  types,  arrays,  records,  access  types,  packages  as  weU  as  an  encap¬ 
sulation  mechanism  for  abstract  data  types,  and  parallelism. 

N.  E.  MILLER  AND  C.  PETERSON,  File  Structures  with  Ada,  Benjamin-Cummings,  Menlo  Park,  Califor¬ 
nia,  1989.  aSBN-8053-0440-l;$39.95/text) 

G.  MENDAL  AND  D.  L.  BRYAN,  Exploring  Ada:  Volume  2.  Prentice-Hall,  Englewood  Cliffs,  New  Jersey, 
1992.  aSBN:  0-13-297227-1)  (See  Volume  1  under  Bryan) 

A  method  of  presentation  based  on  the  Socratic  method,  provides  coverage  and  the  semantics  of 
Ada.  Discusses  focused  problems  individually.  The  second  volume  expands  on  the  larger  issues 
dealing  with  Ada’s  more  advanced  features. 

G.  L.  MOHNKERN  AND  B.  MOHNKERN,  Applied  Ada,  TAB  Books,  Blue  Ridge  Summit,  Pennsylvania, 
1986.  326  pp.  aSBN:  0-8306-2736-7) 

Intnxluces  the  Ada  language  on  a  practical  level.  Targets  persons  who  understand  the  basic  termi¬ 
nology  and  concepts  of  programming.  (A  particular  language  is  not  a  prerequisite.)  Instructs 
through  examples  of  programs  written  in  Ada. 

D.  R.  MUSSER  AND  A.  A.  STEPANOV,  The  Ada  Generic  Library  Linear  List  Processing  Packages, 
Springer- Verlag,  Berlin,  1989.  265  pp.  GSBN:  0-387-97133-5:  $39.00/trade) 

Discloses  the  purpose  of  the  Ada  Generic  Library  as  an  attempt  to  provide  Ada  Programmers  with 
an  extensive,  well-documented  library  of  generic  packages  whose  use  can  substantially  increase 
productivity  and  reliability.  Contains  eight  Ada  packages,  with  over  170  subprograms  for  various 
linear  data  structures  based  on  linked  lists. 

D.  NAIDITCH,  Rendezvous  with  Ada:  A  Programmer's  Introduction,  John  Wiley  &  Sons,  New  York,  1989. 
477  pp.  aSBN:  0-471-61654-0;  $39,95/paper) 

Explains  Ada  to  the  beginning  programmer  (knowledge  of  at  least  one  high  level  progranuning 
language  is  advised).  Concludes  each  chapter  with  exercises. 

K.  NIELSEN,  Object-Oriented  Design  with  Ada/Maximizing  Reusability  for  Real-Time  Systems,  Bantam 
Books,  New  York,  1992.  (ISBN:  0-553-08955-2) 

Shows  Ada  programmers  how  to  design,  implement,  and  maintain  reusable  real-time  software  sys¬ 
tems  using  the  object-oriented  methods. 

K.  NIELSEN  AND  K.  SHUMATE,  Designing  Large  Realtime  Systems  with  Ada,  McGraw-Hill,  New  York, 
1988.  464  pp.  aSBN:  0-07-046536-3;  $58.95Aext) 

Presents  a  comprehensive  methodology  for  the  design  and  implementation  of  large  realtime  systems 
in  Ada.  (The  reader  is  expected  to  have  a  basic  understanding  of  the  Ada  programming  language.) 

K.  NIELSEN,  Ada  in  Distributed  Realtime  Systems.,  McGraw-Hill,  New  York,  1990.  371  pp.  GSBN:  0- 
07-046544-4;  $58.95Aext) 

Emphasizes  design  paradigms  wd  heuristics  for  the  practicing  software  engineer.  Provides  impor¬ 
tant  background  material  for  the  builder  of  operating  systems  and  runtime  support  environments  for 
distributed  systems.  Contains  data  on  distributed  systems,  process  abstraction  and  Ada  for  distri¬ 
buted  realtime  systems,  design  paradigms  for  distributed  systems,  inter-processor  communication, 
viitual  and  physical  nodes,  and  fault  tolerance. 
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J.  NISSEN  AND  P.  Wallis,  Portability  and  Style  in  Ada.  Ada  Companion  Series,  Cambridge  University 

Press,  Cambridge,  1984.  202  pp.  (out  of  print) 

Examines  style  and  portability  guidelines  for  Ada  programmers.  Results  of  work  by  the  Ada-Europe 
Portability  Working  Group. 

K.  A.  NYBERG,  Ada:  Sources  &  Resources,  Grebyn  Corporation,  Vienna,  Virginia,  1991.  P.  O.  Box  497 

Vienna,  VA.  Telephone:  703/281-2194 

K.  A.  NYBERG,  ED.,  Annotated  Ada  Reference  Manual,  Grebyn  Corporation,  Vienna,  Virginia,  1991.  P. 
O.  Box  497  Vienna,  VA.  Telephone:  703/28 1-2194 

Contains  the  full  text  of  ANSI/MIL-STD-1815A  with  inline  annoutions  derived  from  the  Ada  Rap¬ 
porteur  Group  of  the  International  Organization  for  Standards  responsible  for  maintaining  the  Ada 
language. 

E.  W.  Olsen  and  S.B.  WHTTEHILL,  Ada  for  Programmers,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey, 
1983..  310  pp.  aSBN:  0-8359-0149-1;  $38.00) 

Includes  many  of  the  subtleties  of  Ada  in  a  self-paced  tutorial  foimat.  Contains  the  following:  con¬ 
ceptual  overview;  predefined  types;  expressions;  basic  Ada  statements;  subprograms;  packages;  etc. 

A.  ORME,  ET  AL,  Reusable  Ada  Components  Sourcebook,  Cambridge  University  Press,  Cambridge, 
1992.  286  pp.  aSBN:  0  52 1  4035 1  0;  $49.95) 

The  authors  consider  how  the  Ada  software  components  that  may  be  found  in  this  book  could  be 
used.  According  to  the  publishers  both  the  novice  and  the  expert  software  engineer  will  find  useful 
information  in  this  book. 

D.  POKRASS  AND  G.  BRAY,  Understanding  Ada:  A  Software  Engineering  Approach.  John  Wiley  &  Sons, 
New  York,  1985.  aSBN:  0471-87833-2;  $32.95/i)aper) 

D.  PRICE,  Introduction  to  Ada,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1984.  150  pp.  (ISBN:0-13- 
477646-1;  $26.95/trade) 

Presents  examples,  programs,  and  program  fragments  showing  Ada’s  power  as  a  general  purpose 
language,  plus  step-by-step  explanations  demonstrating  how  Ada  simplifies  the  production  of  large 
programs.  Requires  little  technical  or  mathematical  sophistication. 

I.  C.  PYLE,  The  Ada  Programming  Language,  Prentice-Hall,  Englewood  Cliffs,  New  Jersey,  1985.  345 
pp.  aSBN  0-13-003906-3) 

Describes  the  basic  features  of  the  Ada  programming  language.  Covers  the  issues  of  program  struc¬ 
ture,  and  discusses  machine  specific  issues.  Assumes  prior  knowledge  of  programming.  Introduces 
topics  in  the  context  of  embedded  systems.  Covers  the  following  areas:  the  basic  features  of  Ada; 
the  particular  programming  concepts  in  Ada  that  wiU  probably  be  new  to  most  programmers;  the 
issues  of  program  structure;  the  machine-specific  issues  that  can  be  expressed  in  a  machine- 
independent  language  and  advanced  treatment 

I.  C.  PYLE,  Developing  Sefety  Critical  Systems  with  Ada,  Prentice-Hall,  Engiewood  Cliffs,  New  Jersey, 
1991.  aSBN:  0-13-204298-3;  $39.00/paper) 

A  presentation  of  concepts  for  practicing  engineers  or  programmers  involved  with  the  development 
of  safety-related  computer-based  systems.  Considers  the  different  roles  involved  in  accepting  safety 
related  systems  and  the  corresponding  human  activities.  Illustrates  how  Ada  provides  a  ftamewoik 
in  which  the  design  rules  for  safety  can  be  applied  and  confirmed.  The  author  explains 
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relationships,  with  major  published  guidelines  for  development  of  safety  related  software.  Interprets 
guidelines  specifically  for  Ada.  The  material  presented  is  for  three  contemporary  viewpoints: 
analyzer,  synthesizer,  checker.  A  senior-level  course  in  Ada  programming  and  software  engineer¬ 
ing. 

M.  W.  Rogers,  Ada:  Language,  Compilers  and  Bibliography,  Cambridge  University  Press,  Cambridge, 
1984.  332  pp.  (ISBN:  0-521-26^64-2;  $24.95/trade) 

Offers  a  photo  reprint  of  the  Ada  standard,  a  guide  listing  the  characteristics  of  an  implementation 
that  should  be  taken  into  account  in  the  specification  or  selection  of  an  Ada  compiler  and  a  bibliog¬ 
raphy. 

S.  H.  Saib  and  R.  E.  fritz.  Introduction  to  Programming  in  Ada,  Holt,  Reinhart  and  Winston,  New 
York.  1985.  GSBN:  0-03-059487-1;  $28.95/text) 

S.  H.  Saib  and  R.  E.  Fritz,  Tutorial:  The  Ada  Programming  Language,  IEEE  Computer  Society,  1983. 
538  pp.  aSBN:  0-8053-7070-6;  $25.56/paper) 

Covers  such  topics  as  the  history  and  current  status  of  Ada;  basic  language;  schedule  for  industry 
and  DoD;  preventing  error,  readable  maintainable,  modular  systems;  real-time  features,  portability; 
and  environments  for  Ada. 

W.  J.  Savitch,  ET  AL.,  Ada:  An  Introduction  to  the  Art  and  Science  of  Programming,  Benjamin- 
Cummings.  Menlo  Park,  California,  1992.  (ISBN:  0-805'’ -7070-6;  $33.95/paper  text) 

Written  specifically  for  the  first  programming  course.  It  starts  with  variable  declarations,  simple 
arithmetic  expressions,  simplified  input-output,  and  builds  upward  toward  subprograms  and  pack¬ 
ages.  A  chapter-by-  chapter  instructor’s  guide  is  also  available,  as  is  a  program  disk  with  more  than 
140  completed  programs  from  the  text. 

J.  A.  Saxon  and  R.  E.  fritz.  Beginning  Programming  with  Ada,  Prentice-Hall,  Englewood  Cliffs,  New 

Jersey,  1983.  (out  of  print) 

R,  SHIMER,  Ada,  Amigo  Projects.  1989.  (ISBN:  0-685-30433-7;  $12.00/^apcrtext) 

K.  C.  Shumate,  Understanding  Concurrency  in  Ada,  McGraw-Hill,  New  York,  1987.  595  pp.  GSBN:  0- 

07-057299-2ISBN;  $58.95Aext) 

Presents  a  detailed  exposition  of  concurrency  in  Ada.  Looks  at  five  case  studies  and  gives  an 
advanced  introduction  to  real-time  programming. 

K.  C.  SHUMATE,  Understanding  Ada,  John  Wiley  &  Sons,  New  York.  GSBN;  0-471-605-204; 
$5 1.00/text) 

K.  C.  Shumate,  Understanding  Ada:  With  Abstract  Data  Types,  John  Wiley  &  Sons,  New  York,  1989. 
GSBN:  0-471-60347-3;  $21.50/text) 

J.  SKANSHOLM,  Ada  from  the  Beginning,  Addison-Wesley,  Reading.  Massachusetts,  1988.  617  pp. 
GSBN:  0-201-17522-3;  $29.25) 

Describes  the  principles  and  concepts  of  programming  in  a  logical  and  easy-to-understand  sequence 
and  discusses  the  important  features  of  Ada  (except  parallel  programming).  Teaches  the  basics  of 
writing  computer  p.’ugrams.  Emphasizes  the  fundamentals  of  good  programming.  Provides  a 
grounding  in  the  programming  language  Ada.  Covers  the  following;  programming  designs,  the 
basics  of  Ada,  control  statements,  types  subprograms,  data  stmctures,  packages,  input/output,  excep¬ 
tions  dynamic  data  structures,  files,  and  generic  units. 
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C.  H.  SMEDEMA,  ET  AL.,  The  Programming  Languages  Pascal,  Modula,  CHILL,  Ada,  Prentice-Hall, 

Englewood  CUfiFs.  New  Jersey.  1983.  154  pp.  aSBN:  0-685-08596-1;  $16.95/trade) 

Provides  an  infonnal  introduction  to  the  most  important  characteristics  of  Pascal,  Modula,  CHILL, 
and  Ada.  Discusses  languages  in  historical  order.  Includes  the  history,  application  area,  standardi¬ 
zation  aspects  and  future  prospects  of  each. 

J.  SODHI,  Computer  Systems  Techniques:  Development,  Implementation,  and  Software  Maintenance, 
TPR,  Scarsdale,  New  York.  1990.  GSBN:  0-8306-3376-6)  Phone:  800-822-8 138 

J.  SODHI,  Managing  Ada  Projects  Using  Software  Engineering.  TPR,  Scarsdale,  New  York,  1990.  246 
pp.  aSBN;  0-8306-0290-9;  $34.95/trade)  Phone:  800-822-8 1 38 

Describes  some  of  the  practical  aspects  of  developing  a  flawless  project  in  Ada. 

J.  SODHI,  Software  Engineering:  Methods,  Management,  and  CASE  Tools.  TPR  (a  division  of  McGraw- 
HiU),  New  York.  1991.  GSBN:  0-8306-3442-8)  hone:  800/822-8138 

I.  SOMMERVILLE  AND  R.  MORRISON,  Developing  Large  Software  Systems  with  Ada.  International  Com¬ 
puter  Science  Series,  Addison-Wesley,  Reading,  Massachusetts,  1987.  (ISBN:  0-201-14227-9; 
$26.95/papertext) 

D.  Stein,  Ada:  A  Life  and  Legacy,  MIT  Press,  Cambridge.  Massachusetts,  1985.  321  pp.  GSBN;  0-262- 

19242-X;  $30.00/TYade)  GSBN;  0-262-691 16-7;  $10.95) 

Presents  the  view  that  Ada  Byron’s  mathematical  and  scientific  achievements  have  been  exag¬ 
gerated. 

M.  J.  STRATFORIJ-COLUNS,  Ada:  A  Programmer's  Conversion  Course,  EUis  Horwood  Series  in  Comput¬ 
ers  &  Their  Applications,  John  Wiley  &  Sons,  New  York,  1982.  (ISBN:  0-470-27332-1; 
S56.95/trade) 

S.  TafVELIN,  Ed.,  Ada  Components:  Libraries  and  Tools.  Ada  Companion  Series,  Cambridge  University 
Press,  Cambridge,  1987.  288  pp.  GSBN:  0-521-34636-3;  $44.50/trade) 

Comprises  the  proceedings  of  the  international  conference  organized  by  Ada  Europe  with  the  sup¬ 
port  of  the  Commission  of  the  European  Communities  and  the  collaboration  of  SIGAda. 

M.  TEDD,  ET  AL.,  Ada  for  Multi-microprocessors,  Ada  Companion  Series,  Cambridge  University  Press, 
Cambridge.  1984.  208  pp.  OSBN:  0-521-301033;  $4450/trade) 

Addresses  those  problems  of  distributed  systems  that  arise  out  of  the  nature  of  Ada  and  support 
environments.  Discusses  the  issues  of  how  to  construct  and  run  an  Ada  program  for  a  valuable  tar¬ 
get  configuration  of  several  microcomputers,  interconnected  through  shared  memories  multi-access 
busses,  local  area  networks,  and  end-to-end  lines. 

P.  TEXEL,  Introduction  to  Ada:  Packages  for  Programmers.  Wadsworth  Publishing,  Belmont,  California, 
1986.  44 1  pp.  aSBN:  0-534-06348-9;  out  of  print) 

Provides  a  guide  to  Ada  that  contains  complete  packages,  VO  facilities  and  sample  programs, 
emphasizing  top-down  design  throughout 

B.  A.  TOOLE,  Ada,  The  Enchantress  of  Numbers:  A  Selection  from  the  Letters  of  Lord  Byron’s  Daughter 
and  Her  Description  of  the  First  Computer,  Strawberry  Press,  New  York.  GSBN:  0-912647-09-4; 
29.95) 

The  author  states  that  she  selected  the  letters  in  such  a  way  to  enable  the  reader  to  follow  a  loose 
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story  line  of  Lady  Ada  Lovelace’s  life.  In  her  letters,  Ada  describes  her  thoughts  of  the  first  com¬ 
puter,  and  Ms.  Toole  relates  these  descriptions  to  the  modem  software  language,  Ada. 

J.  TREMBLAY,  ET  AL.,  Programming  in  Ada,  McGraw-Hill,  New  York,  1990.  489  pp.  (ISBN:  U-07- 
065180-9;  $24.60^aper  text) 

Explains  computer  science  concepts  in  an  algorithmic  framework,  with  a  strong  emphasis  on  prob¬ 
lem  solving  and  solution  development. 

J.  UHL,  An  Attribute  Grammar  for  the  Semantic  Analysis  of  Ada,  Lecture  Notes  in  Computer  Science 
Series,  139,  Springer- Verlag,  Beriin,  1982.  (out  of  print) 

B.  UNGER,  Simulation  Software  &  Ada,  SCS  Simulation  Series,  1984.  (ISBN:  0-911801-03-0; 
$16.(X)^aper) 

E.  N.  Vasilescu,  Ada  Programming  with  Applications,  AUyn  and  Bacon,  Newton,  California,  1987.  539 
pp.  (out  of  print) 

Offers  a  bottom-up  approach  to  commercial  and  business  uses  of  Ada  emphasizing  the  features  of 
Ada  that  are  most  like  tnose  of  traditional  languages. 

E.  M.  Vasilescu,  Ada  Programming,  AUyn  and  Bacon,  Newton,  California,  1986.  (out  of  print) 

D.  VOLPER  AND  M.  D.  KaTZ,  Introduction  to  Programming  Using  Ada,  Prentice-HaU,  Englewood  Cliffs, 
New  Jersey,  1990.  650  pp.  GSBN:  0-13-493529-2;  $30.00) 

Uses  the  spiral  approach  as  the  presentation  methodology  in  this  introductory  course  in  Ada  pro¬ 
gramming. 

R,  H.  Wallace,  Practitioner's  Guide  to  Ada,  McGraw-HiU,  New  York,  1986.  373  pp.  (ISBN:  0-07- 
067922-3;  $39.95) 

Discusses  the  issues  to  be  considered  when  making  the  transition  to  Ada  on  selecting  toolsets,  and 
on  using  the  language  effectively.  Covers  the  foUowing:  Ada  as  a  language;  Ada  Oriented 
Development  Environments;  Ada  oriented  design  methodologies;  Ada  policies  and  standards;  Ada 
products  and  vendors;  sources  of  Ada-related  information;  making  the  transition  to  Ada  and  other 
uses  of  Ada. 

Y.  Wallach,  Parallel  Processing  &  Ada,  Prcntice-HaU,  Englewood  Cliffs,  New  Jeney,  1990.  QSBN: 
0-13-650789-1;  $54.00/casebound) 

P.  J.  Wallis,  Ada:  Managing  the  Transition,  Ada  Companion  Series,  Cambridge  University  Press,  Cam¬ 
bridge,  1986.  aSBN:  0-521-33091-2;  $44.50/trade) 

P.  J.  WalUS,  Ed.,  Ada  Software  Tools  Interfaces,  Lecture  Notes  in  Computer  Science  Series,  180. 
aSBN:  0-387-13878-1;  $16.00/paper) 

D.  A.  Watt,  ET  AL.,  Ada  Language  and  Methodology,  Prentice-HaU,  Englewood  CUffs,  New  Jersey, 
1987.  515  pp.  aSBN:  0-13-004078-9;  $37.00/paper) 

Covers  the  Ada  language  in  detail  and  introduces  program  methodologies  appropriate  for  use  with 
Ada.  Discusses  the  foUowing  topics:  1)  covers  a  subset  of  Ada  broadly  comparable  with  most  other 
programming  languages;  2)  introduces  the  features  of  Ada  that  make  it  suitable  for  the  construction 
of  large  programs;  3)  completes  the  treatment  of  the  data  types  of  Ada;  4)  concludes  the  treatment  of 
program  structures. 
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P.  Wegner,  Programming  with  Ada:  An  Introduction  by  Means  of  Graduated  Examples,  Prentice-Hall, 
Englewood  Cliffs,  New  Jersey,  1980.  (out  of  print) 
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